Re: Long Menus issue (Was: Re:NeXTGtk ?)

[Gleef <gleef capital net>]

On Mon, 1 Jun 1998, Zack Williams wrote:
> This came up in a different discussion, but I think it needs to be paid more 
> attention to. The problem is: What do we do when a menu is to long to fit on 
> screen (like a font menu in some GUI's, Gimp plugins). We want to be able
> to see all of the choices in the menu, but most current solutions don't
> work too well. I know that currently font selection does not occur in a 
> menu, but we must deal with cases where applications, especailly extensible
> ones, need to be able to handle such cases gracefully, without any extra 
> code. These are the most common ideas:

Personally, I have yet to see a convincing argument for menus long enough
to need ANY of these solutions.  IMHO all of these solutions are worse
than the problem.  Remember, menus are not for selecting from a boundless
list, menus are for telling the program what to do.


> 1. Have a "More" item that creates another menu next to it - this is what
> a lot of GUI's do - Motif does this. It doesn't work very well, and avoiding
> this solution started the discussion.  

I agree, this doesn't work very well.

In addition, applications not under our control (Window managers are the
most common culprit, but others are certainly possible) will often place a
window that is raised above our menu at the bottom of the screen.  This
would cover the "More" tag, and make the menu unusable.

 
> 2. When the number of items exceeds a certain arbitrary amount, the menu 
> becomes scrollable, or pops up a dialog with a scrollable box in it. This
> could be a good idea, but even if the menu had an area at the bottom that 
> autoscrolled when the pointer was over it, you could not see all of the 
> menu items at once (one of the main complaints)

If the menu itself is scrollable, the only sensible place for the area to
indicate "scroll down" is the bottom of the menu.  See the point above.
In addition, not being able to see all of the menu items at once will make
it confusing as to what is available from this menu, confusing the user,
making the application less useful.

 
> 3. Decrease the size of the text in the menus until they all fit on screen.
> This works, but presents a pragmatic interface, and even with a smaller font 
> there is a limit to the vertical screen size.

I have dealt with many partially vision impared people.  Generally, what
they look for is a system which allows them to set the font REALLY LARGE.
They get very annoyed when the system decides on its own to shrink things.
Without a pressing reason for making GNOME useless for the visually
impaired, I certainly don't think we should.


> 4. Have long menus tile horizontally. Like this:
> 
>  ||||||||||||||||||||||
>  | ITEM 1  | ITEM N   |
>  | ITEM 2  | ITEM N+1 | 
>  |  ...    |  ...     |
> 
> This way, all menu items are displayed on screen. The only cases where this 
> would not work are when there are many very long menu item names, or when
> there are a very very large number of menu items (combine with a smaller
> font size?). Usually menus like this do not have submenus so having menus on 
> top of menus would not be a problem. I feel that this is the best solution 
> to the problem. (AFAIK, this is used in Win95 and MacOS, and MacOS does the
> font size manipulations in some cases)

Allowing for 2+ column menus might have a place, to allow for special menu
organizations, so adding the ability for multi-column menus might not
hurt.  On the other hand, a multi-column menu should not be used just
because a menu is too long.  If the menu is too long, split it into two or
more separate menus by function.  If the menu cannot be split by function,
then rethink your interface.  What you are doing should not be in a menu.

 
> Also, is there some way to change the fonts or colors of items in a
> menu or scrollbox? I haven't coded anything using this yet, but on many
> platforms the font names are printed in the font. This would have to be 
> carefully worked on, because on many systems rendering some fonts (like 
> gothic and other kanji fonts) causes a freeze in interactivity, and for some 
> fonts (the symbol ones) it doesn't work well. Could we find the font type 
> by checking the font encodings (for the foreign fonts) or have a list of
> fonts we know we don't want to treat this way (a fairly complete list would
> not be that hard to make - about 15 minutes work)? 

Again, FONTS SHOULD NOT BE SELECTED BY MENU.  Not unless it is a simple
choice, like "Display in default fixed font" as opposed to "Display in
default variable width font".

Allowing for multiple fonts within a menu also adds a risk.  Many
X-Servers have a tendency to pause long times when grabbing fonts from
font servers.  Sometimes they may even hang indefinitely.  A typical font
server installation will have the few fonts absolutely necessary for
operations locally, and all the fancy fonts remotely.  If you start
throwing all sorts of fancy fonts in the menu, the program might lock
X-Windows just from the user accidentally clicking on the wrong menu.  My
understanding is that this is a fairly common X-Windows bug, that is hard
to eradicate from the server while still following the standards for
accessing font servers.


I have seen many programs made very difficult to use by poor menu design.
The "solutions" above will give poor menu designers tools to make the
menus worse, while giving good designers no advantage.  I would rather not
see "Long Menu" solutions until someone poses a good "Long Menu" problem
that would not better be fixed by other means.

-Gleef