Re: Bug#15080: seyon: bad location in menus
On Sun, Mar 29, 1998 at 06:11:12PM +0200, Yann Dirson wrote:
> Somehow off-topic, there is something I'm thinking about since quite a
> long time: my Apps/Net menu has ~25 entries, and I think it can be a
> pain for new users working such an machine.
>
> What about splitting Apps/Net in sub-categs, mainly Mail, WWW, News,
> and IRC ? People with installs that wouldn't justify this could have
> /etc/menu-methods/translate_menus set accordingly. Maybe it would be
> the default setting in translate_menus to redirect Apps/Net/* to
> Apps/Net ?
Early Warning: I don't use the menu package myself.
Correct me if I'm wrong, but I assume that the problem is this: if you have
only one or two options in a submenu, the additional submenu level means
extra clicking and dragging and it looks silly. But if you have lots of
options, it's good to have a submenu. Because different people have
different packages installed, these conditions can differ on a per-install
basis so no "single answer" is the right one.
At work, I've had the same problem writing an SNMP tree browser. If you've
used SNMP, you know that it has LOTS of sub-levels and many, many of them
only have one or two entries inside. This makes it really annoying to
browse the tree.
The solution I came up with was this: collapse menus with only one/two
entries into the parent automatically. For example, say you have this:
apps/comm/minicom
apps/net/web/netscape
apps/net/sys/telnet
apps/net/sys/ftp
apps/net/sys/ping
It should become:
apps/minicom
apps/net/netscape
apps/net/sys/telnet
apps/net/sys/ftp
apps/net/sys/ping
On the other hand, if we add 'lynx' to the 'web' menu, we might not want to
collapse the web menu after all.
You can tweak it to add even more intelligence. For example, notice that
the 'net' menu above only has four total items inside: that sounds like a
good reason to collapse _all_ submenus directly into 'net'.
I think it's really important that the defaults in user interfaces be
intelligent, because most users will simply accept them and never bother to
change them. In this case, they could (without noticing/caring) waste time
navigating extra levels of menus to find often-used programs. I know we
have overrides, but most people will never discover how to use them or
bother to do it. I'm a huge fan of providing _both_ smart defaults and
flexible overrides when the defaults go wrong.
This approach really worked well for me in my project, and this seems to be
the same problem. Sadly, the company I was working for won't allow me to
release the source code, so I guess you'll have to trust me :)
Just ask if you want any implementation advice, but I (sorry, again) don't
have time to do it myself...
Have fun,
Avery
(the everlasting backseat driver)
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: