Re: Debian menus policy
On Fri, 2001-12-14 at 11:15, Craig Dickson wrote:
> Thomas Hood wrote:
>
> > But programs that are data-oriented also have functions, and
> > so belong in the function-oriented tree too. I don't see any
> > reason why a program should not appear in multiple places in
> > the menu hierarchy. A program might even appear multiple times
> > in one of the two trees---if it has several functions or if
> > it operates on several kinds of object.
>
> But then you have a much larger tree. I think one of the goals of the
> menu design, considering how many programs people can have on their
> machines, is to keep the tree fairly minimal. You want everything to be
> in the tree, but if many things are in the tree more than once, the tree
> gets too big. Also, less-sophisticated users will find it confusing;
> they'll wonder if the A in editing->text is the same A that is in
> text->editors, and they'll bombard debian-user with questions about why
> things are duplicated.
Here I have to disagree. From experience with lusers, I've found that
they rarely understand organization of items in menues. For them,
redundancy is a good thing. It makes it easier for them to find what
they're looking for. They might not even think to look for any kind of
"text editor", be it editors->text or text->editors, but they might
think to look for office->text. Similarly, tho, if I'm looking for Vi,
the last place I'd check is a menu called "office."
The more ways to get to soemthing, the easier it is to find.
>
> > What is most important is that it appear in at least one place; and it
> > will be a convenience to the user if s/he knows that every program
> > appears at least in the function-oriented tree.
>
> Not really. What's important is that the items appear in the most
> intuitive place, or that there is enough information in the menu data,
> and enough flexibility in the menu code, that the user can choose to
> view things according to the criteria that are most important to him.
Agreed. I've seen some distros that try to organize everything by
function. While some users may have loved it, I couldn't find crap.
>
> > Returning to the question of the connection with package
> > classification, what we might do is add new tags to the
> > package description for function and object type which would
> > have the same permissible set of values as there are menu
> > titles. Thus a network-enabled text editor would appear
> > under Apps_by_function|Editors|Text and under
> > Apps_by_object|Text|Editors and the package would have the
> > tags "Functions: editor" and "Objects: text". We could
> > then get debhelper to set up menu entries for us. How 'bout
> > that?
>
> That's the basic idea, I think, though whether both trees are visible
> at once, or you choose which one to display, or something even more
> sophisticated than that, remains to be determined.
Well, talking about that, look back to UNIX roots - small programs that
do one thing, and do it very well, that can all integrate. For this,
I'd recommend allowing the full menu meta information to be accessed in
a nice way; then, allow the program that actually generates the menus to
be easily swapped out or overridden. For example, one user might use
menus-full, another might use menus-functional, and another might have a
custom script.
>
> Craig
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: