Re: Debian menus policy
Brian Nelson wrote:
> Craig Dickson <crdic@yahoo.com> writes:
>
> > Right. I should have made that point clearly in my response to Brian,
> > that I don't believe that the sequence "editing->text->emacs" matches
> > the way most people will think as well as "text->editor->emacs" will. My
> > disagreement isn't that I don't want the menus to relate naturally to
> > the way users think!
>
> I think this arrangement would not produce as nice of a menu
> hierarchy. For example, there's only 2 things you do with text--view
> it and edit it. And since every text editor that's been written in
> the last 25 years or so is also capable of viewing text, a "text
> viewer" is not terribly useful. Therefore, the menu would be heavily
> balanced toward editors rather than viewers.
There might not be a need for an "Editors" submenu under "Text", true.
That's why, in my examples in this thread, I've tended to use sound or
graphics, rather than purely textual tools -- there's more variety.
> I think I read somewhere that humans can optimally parse up to 7
> pieces of information at a time. Any submenu that has more than 7
> entries is going to make it difficult for a user to find anything
> quickly.
I believe that had to do with the number of items a person could manage
mentally (without external references) at one time. This is why, for
example, US telephone numbers are seven digits, with the area code
thought of as a separate value. This way you have two things to
remember, one of which has seven digits (actually, three plus four,
which is even easier to remember) rather than a single ten-digit value.
However, when you have some sort of visual reference in front of you (as
you do when you are browsing through menus), this "seven limit" isn't
really relevant; there is a limit of comfort, but it's much higher than
seven, and I think for now it's more limited by vertical screen space
(how many menu items you can fit into a single column without having to
scroll it) than by the limits of human intelligence.
> The Debian menus fail miserably in this respect. Look at the number
> of entries in Apps->System or Apps->Tools. What a useless mess.
I agree that Apps->Tools is a disaster. But that's because it doesn't
really have any identity; it's just a dumping ground for things that
don't fit anywhere else in the currently-defined set of categories.
Apps->System is a bit better, but it's still not well-organized. A few
more subcategories could do wonders for it.
> I think a structure in which function was at the highest level would
> promote a more usable menu hierarchy by these guidelines, don't you
> think? I think you could cover the functionality of all the apps in
> the menu with ~7 generic functions pretty nicely.
I think some sort of reorg of the menus could do a lot of good, but I
still don't buy a top-level layout consisting of generalized operations
(e.g. editing), rather than of application domains (sound, graphics,
text, games). Part of the problem with the current menus are that they
mix the two models rather arbitrarily and sloppily; so you have both
Apps->Editors and Apps->Text. Which one should I expect to find a text
editor under? Well, in practice, you find it under "Editors", but it's
not obvious why "Text" wouldn't be just as appropriate. What does a text
editor operate on if not text?
So we agree that the current situation is a mess. To make the proper
location of text editors obvious to all, either "Text" or "Editors"
should be eliminated. You'd rather eliminate "Text"; I'd rather
eliminate "Editors".
I'm really intrigued by the idea of allowing multiple dimensions in the
menu data, and letting the user decide what sort of view he wants. Does
that seem like overkill to you?
Craig
Reply to: