algebraicthunk.net/ blog/ entry/ Package management usability

[UPDATE: I'm closing comments on this post, because the spammers have discovered it -- dnb]

Lars says:

The uncomfortability of Synaptic may be partly due to the fact that it is a different model from Windows: you get all your programs from one place, instead of anywhere on the Internet, partly due to just not using Synaptic much at all, and partly due to Synaptic not being perhaps as easy to understand as possible. I personally find Synaptic to be very nice, and use it regularly, but I am biased by having used Debian package managers for over a decade.

Now, synaptic is a lot nicer for users than scary console frontends like aptitude. But it's really a tool for "power users". Here's a quick list just of what I see when I start it (bearing in mind that my UI design skills suck):

So much for superficial observations. There are a few more things that I see that are worth more discussion.

Mechanics of selecting packages

To change the state of a package, you click on the unlabeled little box to its left, then select the correct option from a list containing "Unmark", "Mark for Installation", "Mark for Upgrade", "Mark for Reinstall"...you get the idea. Even if only one option is valid, the menu still appears with all but one option grayed out, and you have to select the one you want.

This is complicated, cumbersome, and surprising. It also introduces terminological confusion, since "Unmark" isn't really what you think of when you go to cancel an installation or whatever.

The best option I can think of here is a pulldown menu (which I believe the GTK+ list widget (god, I almost wrote "control") supports). The menu should default to the current state, e.g., "not installed", and should have options that describe what will be done with the package, e.g., "install", and so on. Only valid actions should appear on the menu. The Package menu should probably adapt in the same way as you select packages. I don't recall offhand how GTK+ menus work, but if possible commonly used commands like "remove" should be closer to the mouse when the menu appears than uncommon commands like "reinstall".

Another choice I can see, if you want to avoid menus, would be something like this: have two checkboxes, one for "install" and one for "upgrade". "install" would be checked for installed packages and not checked for not-installed packages. Checking or clearing it would mark packages for installation or deletion. "upgrade" would mark or unmark packages that were installed for upgrade. Of course, this introduces a redundant column for not-installed packages, which I don't like. It also seems to me that it would be less obvious what's going on for new users. But it would be more efficient for power users (who should all be using aptitude anyway ;-) ).

Progress bar madness

I haven't extensively used synaptic, but several core misfeatures of apt and our archive pretty much guarantee that if it displays progress bars for key operations like loading the cache or updating the package lists, the progress bars either run multiple times (i.e., don't actually tell you how close to finishing you are) or actually go BACKWARDS -- yes, BACKWARDS.

The great package hunt

Maybe the biggest problem is that unless you know what package you're looking for, basically all our package interfaces are useless. There are lots of fancy searching features you could add, but actually a quick test in synaptic suggests to me that this would be going in the wrong direction. Unlike aptitude, synaptic includes descriptions, and searches for stuff users might actually want (like, say, "burn CD") seem to turn up relevant results (i.e., software that burns CDs).

I'm sure the search algorithm could be improved (with inexact matching, better indexing (a package description suffix tree?), etc), but the big problem I see is that you tend to get back several dozen results, many of which are libraries, development packages, command-line software or software that doesn't work; some of the other software is software that can burn CDs but whose purpose is not to burn CDs (e.g., backup software).

How can we solve this? The first thing that springs to mind for me is to use popularity-contest data to weight the list. I know it's not terribly accurate, and it has some skewing problems (stuff in the default install will be favored), but I suspect it would greatly bias the results in terms of software that's useful to many people (using the "recently used" tallies might especially help here).

I don't have many other good ideas on the searching problem; I've seen vague suggestions of counting reverse dependencies, but this doesn't seem like a good metric of useful software to me; trying to extract more information from the short and sometimes inaccurate package descriptions seems like a really hard problem to me. (Google can do cool statistical analysis partly because it has so much data to work with AIUI; even a single Web page typically has orders of magnitude more information than a package description)

Another issue is the problem of finding related software once you've installed one piece. We have "suggests" and "enhances", but they aren't exactly displayed in a prominent or easy-to-understand way by any frontend. I think it might be good to display a clickable list of suggested packages somewhere visible (e.g., at the top of the description box) when the user has selected a package for installation. We could even display a little bar, like on (eg) Amazon: "Debian suggests installing these packages..." ;-)

It might also be interesting (if this is considered acceptable; since the data is anonymous I don't see a problem) to analyze the popcon data to find out what packages are being installed in tandem. I don't know if we have enough information to do it, but it could turn out to be really useful to be able to click on a package and see other packages that are popular with users who installed that package. Going back to online stores again, those "other people who bought 'Types and Programming Languages' also bought 'Introduction to Category Theory'" links are amazingly useful, and something similar would probably be a big help in Debian.

Comment by dottedmag at 1:16 AM:

I like the Nokia 770 approach: only the applications from specific categories are available for installation, unless expert mode is enabled.

This approach won't work "as is" with Debian categories, unfortunately, as they are mostly implementation-based (say, perl or python categories), and not task-based.

Comment by Michael at 12:55 PM:

If you want a non-power-user UI, try gnome-app-install (under Ubuntu this is 'Applications > Add/Remove...').

Comment by dburrows at 7:57 AM:

dottedmag,

If there are Perl and/or Python programs in the "perl" and "python" categories, file bugs against ftp.debian.org to have them moved. Those categories are for Perl and Python programming tools.

Michael,

I am aware of gnome-app-install (although it doesn't exist on Debian), but I was responding to a question about why a newbie doesn't like synaptic, hence I talked about synaptic. :-)

Comment by dburrows at 8:00 AM:

Following up on my earlier comment (hit "publish" too fast), I agree in general with the idea of hiding some software from newbies, but I also agree with the notion that we don't presently have a good way of dividing software they should see from software they shouldn't. The note about Perl/Python should have been a side note.

Comment by dburrows at 6:43 AM:

Closing comments on this post: the spammers have discovered it.