debian package browser

era+debian@iki.fi era+debian@iki.fi
30 Jan 2004 16:58:55 +0200


On Fri, 30 Jan 2004 15:31:35 +0100, Hervé Eychenne <rv@eychenne.org>
posted to deb-usability-list:
 > I don't think the naming is so bad... I think it is what most
 > people would expect, and it's simple to use. When you have a ui
 > (user interface) tag associated to a package, people expect the
 > package to contain a program that is a user interface, and that's
 > all.

Following this thread from the side (and not really having looked at
the browser prototype in question) this sounds like the tags are
mostly based on technical features, whereas what users would probably
need are tags based on tasks. "I want to surf the web" could be one,
and "I want to read my email" could be another. And Mozilla could be
listed in both. But then you have a problem with focus, because you
frequently then get into "I +only+ want to read my mail, not have some
silly web browser take up a zillion gigabytes on my hard drive!" and
so on and so forth.

What this suggests to me is some sort of "focusing" mechanism, i.e.
(simple but perhaps effective example) sort by inverse number of tags
for each package.

Incidentally, Freshmeat has exactly this problem, too. If you know
what you want and it's even slightly esoteric, you end up in a twisty
maze of little categories, all slightly wrong and slightly right.

But the first problem is to get consistent and useful tags in place.
Probably it's not even fruitful to criticize the current browser
prototype for problems in the tagging.

If you categorize into a list of simple tasks you can brainstorm up in
one afternoon, you soon get into trouble with software which isn't so
cut and dried. A lot of the available Debian packages are, after all,
pretty technical, and will not easily fit into any simple model of end
user needs. And if you take a wrong turn at some point during the
refinement of your categories, you end up with a mess.

What if one were to start with a bunch of volunteers who keep a simple
log book. (I have been doing this for other reasons for a while now.)
Every time you install a new package, make a note about it in the log
book, and try to categorize it on the fly. After a while, go back and
try to refine what you have so far. Iterate a few times. After a
while, look at the categories which different users have made up for
themselves, and try to make them line up somehow. Then use that as
your starting point for further work.

Packages which are pulled in because other packages depend on them
should not get any tag at all. If I never wanted to install it, I
didn't really "need" it and would not go searching for it.

There are obviously cases where this is not true, but I've simply
looked through my fingers and figured that if I ever miss them, they
will eventually end up in the log book on one of my systems.

FWIW, I have three of these logs so far (laptop, server, work
machine), plus some minor debris from systems I quickly set up for
some special task (DMZ firewall machine; failed "surfing station"
project I tried to set up at home on an old laptop once). I don't
think I have the time to go over the logs any time soon but if you
like the idea, perhaps I could elaborate on this idea some more.

/* era */

-- 
formail -s procmail <http://www.iki.fi/era/spam/ >http://www.euro.cauce.org/
cat | more | cat<http://www.iki.fi/era/unix/award.html>http://www.debian.org/