On Sat, Mar 15, 2003 at 09:15:24PM -0800, Osamu Aoki wrote:
> > 12585+ packages are an interesting problem which poses non trivial
> > usability problems and calls for some research on information
> > visualization techniques.
>
> Spend 20 seconds to assign several keywords to a package
>
> 12585 binary packages translates
> 12585 * (20/60) * (1/60) hours = solid 69 hours :-)
>
> It is non trivial. (I guess Daniel spent at least 20 solid hour
> even with 10 sec/package speed to finish for woody)
>
> Just to finish current one within current structure, I see over 20 more
> hours to do it. Long hours... (If we go by source package there are
> about 7000 packages in unstable) *non trivial* for sure.
So true! However, all these packages have developers that take care of
them, and we should delegate the cathegorization to them, as we are
doing now with sections. If a devel chooses bad cathegories, people
could file bugs; for the common case, however, we could expect that the
majority of packages will easily get a good cathegorization with little
effort.
> Anyway, Enrico, you seem to have lots of interesting ideas and programs
> in terms of algorithm. Before launching implementation, maybe we should
> set "expectation" and "success criteria" for menu system from user's
> perspective.
So, so, so true!!
> Let's list wish list:
Before the wish list, I propose to do a step back and do some task
analysys.
<brainstorm>
<call-for-contributions>
I definitely welcome other brainstormers to join in and create good,
comprehensive lists, which could serve as a basis to identify what we
are going to address.
</call-for-contributions>
* Intended users
- Newbie Linux users, not in charge of administering the system
- Newbie Debian users, not in charge of administering the system
- Experienced non-technical Debian users, not in charge of
administering the system
- Experienced technical Debian users, not in charge of administering
the system
- Debian developers, not in charge of administering the system
- Newbie Linux users, in charge of administering the system
- Newbie Debian users, in charge of administering the system
- Experienced non-technical Debian users, in charge of administering
the system
- Experienced technical Debian users, in charge of administering the
system
- Debian developers, in charge of administering the system
* Purpose of the application
The package manager application is a complex one, in that it is used for
many different purposes.
- Navigation among the available packages
- See what is available (what is in this Debian thing?)
- See what kind of problems or tasks have some package in Debian
that address them (what can I do with all these packages?)
- Examine the different alternative implementations for a given
feature (what choice of word processors do I have?)
- Search the package database
- Find a specific package
- By package name (I want to see gnumeric package informations)
- By incomplete package data (what was that package I used last
year, it sounded like abi-something?)
- Manage the set of installed packages
- See what is currently installed in the system
(what has my system become?)
(disk is nearly full: do I have something I could remove?)
- Add/remove a single package (I wish to have libgnome2-dev for my
project)
- Add/remove a feature (I need a web server)
- Manage dependencies
(this package depends on these others: do I still want to install
it?)
(removing this package would involve removing these others: do I
still want to remove it?)
(this package wishes to have a web server: which of the different
alternative ones should I choose?)
(this package suggests this other one: do I want it?)
- System-wide actions
- Upgrade the system
- Upgrade to the next stable distribution
- Remove cruft packages
Other random ideas might be:
- show which packages are currently uninstallable
- show which of the installed packages have open
important/grave/critical or security bugs, or open bugs reported by
me
- show which of the installed packages have been orphaned
</brainstorm>
Once we have some analysis and we documented a set of tasks the
application is to be used for, we will have a strong, common ground from
which we can proceed:
- evaluate how is the current situation: where it is good and where it
needs improvement
- elaborate proposed solutions and evaluate them
- build a roadmap for implementation, scattered with some user testing
- code, re-evaluating the current situation from time to time
> Once we exhaust these wishlist and prioritize them, we write down how to
> assign some key words/properties to each package. Split the task, then
> consolidate data to create final data.
At the LCA2003 BOF, in the limited time we had, we came out with these ideas
for improving package metadata:
- More than one section (tag/cathegory) per package
- Different instances of package descriptions: an application could
have a "general" description and a "technical" description for issues
of interest only to developers
- List of supported mime-types, to allow the user to do something like
"I want to view an application/postscript file: which packages are
available to do that?"
And then it was acknowledged that most of these metadata are not unique
inside the debian universe, but could be different for each distribution
flavour. tuxpaint could have "toy" and "paint" cathegory in one debian
flavour, but only "paint" cathegory in a Debian Juniour flavour.
Also descriptions and priorities could change.
In fact, we considered the idea that creating a different debian flavour
could mostly be limited to creating a set of different package data,
priorities being the most important ones.
It was thus stated that flavour-specific data, like package sections,
package priorities, default package selections and other user-related
data, should not be inside packages themselves, but in external sources.
There are a dangerous lot of issues to address here. I'm stuck between
the fear of bringing too many issues in the discussion and get lost
among them and the fear of holding issues to facilitate the discussion
but then have to rework everything later on.
I think, however, that the time has definitely come to start to
seriously address this kind of user-centered technical problems.
Bye,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>
Attachment:
pgp85NK2VIP0F.pgp
Description: PGP signature