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

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.

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

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

>         * 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.

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.


# Zack Williams #
#                                                                 #
#   Linux is like an arcwelder - it is insanely powerful in the   #
#        right hands, but most people get by with JB Weld         #

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]