Re: Debian menus policy
Craig Dickson wrote:
>
> Brian Nelson wrote:
...
> > 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.
people can hold in short term memory about 7 items, they can visually
process only about 5 items. If you have more on the screen at one time
it slows you down considerably (even though having them placed in some
meaningful way (e.g. ordered alphabetically) helps).
> 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
exactly. editing does not really mean anything - there would be
applications that are entirely different, never used together in such a
menu. not a good thing. you want relevant apps in the same menu (even
more so when you can 'pin' the menu)
> 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?
but then you have some html editors under editors and some someplace
else (tools? net? I forgot).
...
> 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?
IMO that's very reasonable way to go. but some serious work needs to
be done to figure out which categories are most useful and how to enable
user to build menus using the info available (that's closely related to
what info is stored about program/package, IMO)
erik
Reply to: