Re: why kde and gnome's menu situation sucks
On 10/23/2002 10:47 PM, Chris Lawrence at firstname.lastname@example.org wrote:
> IIRC the deepest hierarchy possible in my current code is 4:
> Education/Scientific/Something/Group. However, the odds of you having
> enough Ed/Scientific/Something for Ed/Scientific/Something/Group to
> not end up as Ed/Group or Ed/Scientific/Group are about zero.
> (Something is "Astronomy" or "Physics" or a bunch of other things.)
> And this assumes you have multiple menu entries for the group, another
> rare possibility.
A few thoughts. I would hate to see most of the submenus drill down any
deeper than two levels below the main menu. By this, I mean:
Level 1- Start Menu; Most common tasks,i.e. "Find"; broad Submenu categories
Level 2 - Submenus Foo, most commonly used applications
Level 3 - Application Foobar (deepest level used if at all possible)
Requiring a user to drill more than three levels is a bit too much. The
shallower the Menu layout, the easier it is to use. Of course, this means
sacrificing the ability to list all available programs, but that option can
be made available - debate still ongoing on exactly how to do this.
> On the other hand, overload in one menu (like System or Accessories)
> is distinctly possible. But that's why we can add additional
> categories to break it down a bit.
Yup. Good menu design requires really careful thought given to submenu
categories and their layout - with no overload in any one area. A delicate
balance between completeness and simplicity must be maintained. Ya can't
have a start menu that is stands a virtual four feet tall, and ya can't have
deeply nested menus drilling down into the nether regions.
I hope to be able to get working on this soon, and come up with some
concrete suggestions for review and revision. Brainstorming session needs
to go on a bit longer though I think.
> Some expertise things could also be added to cull this further.
> Another possibility: the alternatives system could be overloaded to
> allow e.g. core entries for "wordprocessor.desktop", "email.desktop",
> and "browser.desktop" (and others if deemed important) that would
> depend in part on your installed packages and in part on their alt
> priorities, kinda like the WinXP new-style start menu has a few major
> app links in the core, with access to All Programs as a separate
> (Of course, that means we need a cool GUI to manage these and other
> alternatives; I guess using debconf would be permissible in this case,
> since the state you have to worry about is all simple, no comments or
> anything to preserve.)
On these matters, I will have to defer to those with knowledge in these
areas superior to mine. Sigh. . . I'm not a total tech wimp fellahs - I
still remember some BASIC and Pascal from my hacking days in my youth ;-)