[interfacekit] Re: Accessing 2nd level menus
- From: Jeremiah Poling <sonicpling@xxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Mon, 10 May 2004 20:05:29 -0500
Axel Dörfler wrote:
Hi there,
I've got aware of a nice thing in at least Dano (dunno about R5): when
a menu has a (open) submenu, you can move the mouse cursor over other
items on the way to that submenu as long as you don't stop moving.
Interestingly, this only works as long as you move the cursor in the
direction of the submenu; if the menu is on the right and you move the
cursor to the left, the menu will close immediately after you've left
the area of the originating menu item.
If you ask me, we should not only copy this behaviour, but also wait a
tiny bit until closing the menu if the mouse cursor movement is
interrupted (as you don't always move the cursor that smoothly).
Both of these helps the usability of these menus quite a bit.
Bye,
Axel.
Here's some good info:
Question 6
What is the bottleneck in hierarchical menus and what technique
used on the Macintosh, but not on Windows, makes that bottleneck
less of a problem? Can you think of other techniques that could be
applied?
The bottleneck is the passage between the first-level menu and the
second-level menu. Using Windows, users have to slide across just right,
least they slip down to the next menu at the last moment.
When I specified the Mac hierarchical menu algorthm, I called for a
V-shaped buffer zone, so that users could make an increasingly-greater
error as they neared the hierarchical without fear of jumping to an
unwanted menu. As long as they are moving a few pixels over for every
one down, on average, the menu stays open. Apple hierarchicals are still
far less efficient than single level menus, but at least they are less
challenging than the average video game.
The Windows folks instead leave the hierarchical open for around a
half-second before jumping down. Thus, as in so many of the other areas
of their OS, they mimic the Mac without getting it right. They have
decoupled cause and effect by 1/2 second, a long, long time in
human-computer interaction. If you happen to get to the hierarchical
within that half-second, the Windows behavior is indistinguishable from
the Mac. If you don't, the behavior is just weird and few users can
figure the rule out.
Here's the Source:
http://www.asktog.com/columns/022DesignedToGiveFitts.html
Here's More:
http://mail.gnome.org/archives/gtk-devel-list/2000-May/msg00114.html
- Follow-Ups:
- [interfacekit] Re: Accessing 2nd level menus
- From: Jeremiah Poling
- References:
- [interfacekit] Accessing 2nd level menus
- From: Axel Dörfler
Other related posts:
- » [interfacekit] Accessing 2nd level menus
- » [interfacekit] Re: Accessing 2nd level menus
- » [interfacekit] Re: Accessing 2nd level menus
I've got aware of a nice thing in at least Dano (dunno about R5): when a menu has a (open) submenu, you can move the mouse cursor over other items on the way to that submenu as long as you don't stop moving.
Interestingly, this only works as long as you move the cursor in the direction of the submenu; if the menu is on the right and you move the cursor to the left, the menu will close immediately after you've left the area of the originating menu item.
If you ask me, we should not only copy this behaviour, but also wait a tiny bit until closing the menu if the mouse cursor movement is interrupted (as you don't always move the cursor that smoothly).
Both of these helps the usability of these menus quite a bit.
Bye, Axel.
- [interfacekit] Re: Accessing 2nd level menus
- From: Jeremiah Poling
- [interfacekit] Accessing 2nd level menus
- From: Axel Dörfler