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

[Gleef <gleef capital net>]

On Wed, 3 Jun 1998, Zack Williams wrote:
> Ok, in their basest form, menus are used to execute commands on data, or
> change how the rest of the commands work on data. For these to requirements
> to be met with the greatest of efficency, we should:
> 
> A. Try and make as many menu items appear on screen at once as possible -
>    Give the user all options at once.

As someone has already corrected me, X is occasionally run on some pretty
obscure and cramped hardware implementations.  While fully supporting all
of them shouldn't be a priority, making sure GNOME isn't broken on them
would be very useful.


> B. Minimize the distance that the mouse has to travel, for fast usage.

Agreed, minimize the distance, and the number of mouse clicks.  Whatever
method is used should also make sense with reasonable keyboard access as
well, not everyone has a mouse, even when using X, and far more have mice,
but would rather not use them except for drawing or other tasks that don't
make sense without a pointing device.


> C. All menu items should be displayed, no matter how many there are.

This almost like A, ditto the comment here.

> >         * Use a drop down list for menus.  This puts a scroll bar on the
> > side of menus which are too long.  This may be my favorite solution.  I
> > might like it more if the scroll bar looked like this:
> > 
> >                        /\ So you can scroll up/down easily.  I also
> >                        \/ think this scroll bar should be VERY thin
> >                        .. and should be auto scrolling.  This means
> >                        [] that if the user drags the mouse to the
> >                        .. top of the screen, the menu scrolls up.
> >                        .. (Works with the bottom too.  This would
> >                        /\ only be if the user has not released the
> >                        \/ mouse button.)
> 
> I like this idea too. Tbe only thing I dont like about it is that 
> depending on how people use the mouse, it requires more clicks than
> the multi-column idea. It also requires the user to do more than when
> confronted with a normal, not scrollbared, menu. It loses out in point
> A because you always have to scroll to see everything, and it looses out
> in point B because scrolling down for a long ways will always take a
> farther mouse movement than moving in more than one dimension. It does
> win in point C, because you can have an unlimited number of items in a
> scrolled menu.
>
> >         * Create menus which are multiple columns.  This isn't a bad idea
> > either.  New Menus for Windows uses this at times.  Photoshop uses it too.
> > I guess the Start button on Windows95 uses this as well.  But it isn't
> > something which should be created at run time. The menu needs to be
> > organized in this column format by the programmer.  This lets developers
> > layout the menu correctly.
> 
> I say that we do it automatically, and try and devide the menus along 
> the horizontal separators whenever possible. A smart algorithm that 
> would reorder menu items so they fit in two even columns would be another 
> useful feature. This idea wins over the scrollbar idea in both points
> A and B, and could be extended using a scrollbar to make it even better
> than having only a scrollbar in a menu.

The issue is support for users with tiny screens.  Multi-column menus
would help so few of those users as to be a non-solution.  Tiny screens
are often taller than wide.  How would a multi-column menu handle a screen
that is both two narrow and too short?

> Ideally, we would have a menu that would split into two columns if it
> was more than 3/4 of the size of the screen, to make it easier to get
> to all of the items. In case of more items than is practical to fit on
> screen using columns, scrollbars should be used. This way, we get the 
> best of all worlds.

Having three different ways to view menus sounds like an unnecessary
complication, and will be confusing to the end user.

For tiny desktops, the only two options presented so far that will do the
job are the "More" tags and varying implementations of scrolling menus.
It seems like the consensus is that "More" tags are inferior to scrolling
menus.

The three different types of scrolling menus I've seen mentioned are:
A) A menu with the top and bottom items up and down arrows, with all the
   items scrolling between them (cf. IE4 Active Desktop's Start Menu)

B) A menu with a scrollbar on the right, looking suspiciously like a combo
   box with no entry area. (The idea above)

C) A menu with 'hot' areas which will cause the menu to scroll just by
   moving the mouse to or past the right spot.

I think that, while C has a lot of technical merits over the other two,
it will cause new users to freak out ("Aaaah, my menu keeps moving"), and
will never get accepted by the Click-to-Focus crowd.

Of A and B, they will be equally confusing to new users ("I clicked on the
File menu, and I don't see 'Exit' anywhere?!").  Since B shares
functionality with a more common widget (the combo box) it is likely to be
easier to learn.  In addition, the ability to scroll the menu either line
by line or page by page, or even position the box to where you know the
item will be, makes B superior for experienced users.

I think that having a menu undecorated by default, and get the scrollbar
when height becomes an issue makes the most sense.  Anybody wanna make a
patch to be looked at?

-Gleef