Re: debian package browser

On Fri, Jan 30, 2004 at 01:46:48PM +0100, Erich Schubert wrote:

> > > It's often easier to check a list of 10 packages than checking 5
> > > subgroups for 2 packages each.
> > 
> > That's not my point of view.

> Well, but that is the design principle of the web frontend.

It would be good to leave the choice, I think (only a small button
would allow both views), with your view by default...

> > > The package browser aims for people not knowing that.

> > And what are they supposed to be looking for, then?

> "i need something for email", and then be guided the way by the given
> subgroups.

Ok, let's say I'm looking for an email client.
Please take a browser and do everything like me from now on. ;-)

Well, I start from http://debian.vitavonni.de/packagebrowser/

Here's what I do to find an email client:

I click on Application.
I click on User interface.

Ok? An email client is an application and a user interface, right?

Now I click on ... Oh, I'm lost.
I get presented:
- GTK user interface
- Games, fun and entertainment
- Utilities
- QT user interface
- File formats
- Editors
- IP Networking
- Scientific and mathematical software
and nothing fits (I don't want to limit to GTK interfaces, sorry).
Too bad. And _wrong_.

I'm destabilized... So I guess I must click on "Back"...
Well... now let's say I try to change "User interface" by the next
subgroup which matches my need "Network and Communication".
(Remember it's already wrong that I had to do that.)

Ok, now I see Email. Good, I'm reassured. So I click on Email.
The subgroups presented to me are now:
- IP protocol support
- Editors
- Documentation
- Software Libraries
- Filters
- File formats

I'm looking for something like "User interface" (the entry I just say
before), but cannot find it!!
Wrong, once more.

Well... no subgroup fits to what I'm looking for, so I think that's
it, and so I try to wander through the whole list of packages.
But there are 26 of them... Oh...
Well, let's go anyway.

So (because I'm a clever guy ;-) ), instead of reading every package
description, I see that I can read the lines in grey (please pardon
me if I tend to think that people are generally not so clever, but I
met already too many end-users to imagine that not everyone would do
this).
But each line in grey contains a whole list of tags, and reading them
is quite painful, I think to myself.
But in the end, there is worse: I still cannot find what I'm
looking for!!! (no email client is displayed at all)

Then, because I'm a computer scientist, I now that email is related to
SMTP, which is based upon TCP, which is based upon IP protocol.
And I remember having seen "IP protocol support" in the list of
automatic subgroups.
(_But I'm not supposed to know all that!!!_ And if I don't know, I'm
definitely lost)

Well... let's suppose I know that, and click on "IP protocol support".

Ok, now I have 3 subgroups:
- Mail transfer via SMTP
- Mail access via IMAP
- Mail access via POP3

Well... I'm not convinced. All I want is an email user interface...

There a 2 packages presented here.
The first is openwebmail... but I don't want a webmail.

And the second is pyne.
Ok, now I've found _one_ package. Great, isn't it? ;-)

Ok... let's suppose I know there are several packages which provide a
email user interface on Debian (and I'm not really supposed to know
that, once more).

All I can do is telling myself that I missed something.

I see "Mail access via POP3". But I want to read the email that is in
my local box! Anyway, let's suppose that I click on "Mail access via
POP3",, by curiosity...
Yes... I vaguely heard about POP3 one day (sigh). But only daemons are
presented here.
So, completely desperate, I try to see what's in the only category
"Mail access via IMAP".

And that's is, I find things like mutt and mozilla. And still, I've
only discovered 3 packages, as we all know here there are many more.


Do you understand, now, how I think your search strategy can really be
_disastrous_ for the end-user?


Not only the search process I presented here was very long, forced me
to get back at some stages, requiered that I'm aware of technical
details, but in the end... I did not even get what I wanted.
Frankly, if you don't understand what I mean now, I cannot do anything
else.

Please, don't tell me "you could had done it like this, or like this".
I know there must exist a path which lead exactly to what I intially want.
But search is not about knowing in advance what we'll get, and how to
get it, no.
So I consider there are big flaws in the current interface.


With my strategy, you get what you wanted in the end, with a clear
process that does not take too long :

The sequence for search is:
1) display all "root" tags (those who are not implied by others),
   sorted by order of cardinality
2) select a tag
3) display tags that match this algorithm: find all packages associated
   to the already selected tag(s), and list the other (not selected
   yet) tags associated to all of these packages. Then choose among them
   the non-implied tags (and display them by order of cardinality)
and go on with 2), and so on, until you find what you found exactly
what you need in between 5 and 10 clicks.

For me, that's the interesting way of doing things.

> > Tagging is far more superior to a silly string matching.

> > When I'm looking for an IDS, I want to choose several tags, which
> > finally give me the one I want : "Intrusion Detection System", and get
> > presented a list of _all_ the packages that deal with intrusion detection,
> > and maybe some more "subcategories" which enable me to refine my search a
> > little more (dameon, library, etc,....)

> You can do that, but there is no navigation path for that _special_
> small tag in the UI.

> http://debian.vitavonni.de/packagebrowser/?tags=security::ids

Maybe you could add it? ;-)

> But if you want to provide a navigation path to every tag it gets
> unuseable.

Once more, I don't think so.

> "Link overload" kind of. Most people are confused by too many
> choices and too many links.

> > That is clearly the best way of doing things, in my opinion.

> I tried building all subgroups, and it annoyed me. I had to click a
> dozen times more to see the same data.

I think you didn't implement all the stategies that enable to reduce
choices.

> That is why i decided to do it the other way.

Anyway, this other way is currently flawed, as I demonstrated...

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/