Re: Submenu navigation

[Nils Barth <nils_barth post harvard edu>]

Thus spake David Santiago:
> I actually spent some time working on this. I currently have it working so
> that when the mouse cursor leaves a menu item, the menu it left stays up
> for a moment before the new menu pops up. Haven't yet had any luck
> cancelling the pop up of the new menu if it enters the still-up submenu,
> though. 
> 
> As to whether that is how the Mac does it or not, I am not sure. There is
> definitely a timeout. The only two things I could point you to are 
> 
> 1) From the Apple Human Interface Guidelines, page 103: 
> 
> Hierarchical menus are menus that include a menu item from which a submenu
> descends. You can offer additional menu item choices without taking up
> more space in the menu bar by including a submenu in a main menu. When the
> user drags the pointer through a menu and rests it on a hierarchical menu
> item, a submenu appears after a brief delay. 
> 
> (You can grab this entire book in PDF on Apple's web site, it's a great
> read). 

Agreed.
Indeed, do you know if anyone is working on a GNOME UI guidelines
document?
Similarly, is there a UI behaviour document that describes how
GTK/GNOME widgets/apps work? A little non-technical thing that
included stuff like what different buttons do to spin-buttons?

> 2) From David K. Every's MacKido.com
> page: http://www.mackido.com/Interface/hysteresis.html
> 
> In this page, he goes into relatively deep detail about how submenu
> hysteresis works. He says it is done with a delay, and nothing about a
> triangle, but says that it is dependent upon the user moving his mouse
> towards the menu item when it leaves. (Of course, doesn't mean it can't be
> implemented with a triangle like that). 

Thanks for recalling that webpage!
As a reference, I've been using
http://www.asktog.com/
which is run by Tog, an old, bitter guy who helped design the original
Mac UI.
There are actually two separate UI issues, and MacKido confuses them a
little:
(1) Pause before menus are drawn (so less flicker when navigating)
(2) Easy selection of submenu items.

(1) shouldn't be too hard, and I haven't been working on it.
Basically, have a customizable timeout such that the submenu is only
painted/realized after the menuitem has been active for a short while.

Your work seems to be in this direction, and I'd love it if you could
make a patch to that effect.

(2) is what I've been working on. Here's what Tog, the person who
specified the Mac submenu UI, has to say:

taken from:
http://www.asktog.com/columns/022DesignedToGiveFitts.html

--------------------------------------------------------------------
Question 6

Q:
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?

A:
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.

--------------------------------------------------------------------

Fiddling with the Mac, I figured that the behaviour was actually as I
described. Here's some examples of what I did:
Go towards a menu item, then back up, wait around.
So long as you stay within the triangle, it doesn't die until the
timeout.
I originally imagined doing something with motion callbacks to see
that you were ``moving in the right direction'', but this is baroque,
and the Mac does it in a much simpler, equivalent way.
I think what I call the triangle, he calls the V-shaped buffer zone.

> Another idea would be to dig up the Mozilla source code. You may have
> noticed that their submenus have this behavior implemented very nicely. I
> haven't looked into this at all, though. 

Haven't thought too much about it -- the Mac design seems to be
correct, though the Mozilla code might give implementation ideas --
thanks!

> Lemme know if you'd like to see the patch I have so far (Not anywhere near
> finished, and I'm not even sure it's the right way to proceed. I was just
> looking into it, and haven't had much time for exploration).

So actually, your patch seems to act more like the Windows behaviour,
which is 1/2 right.
However, if you made the delay instead come at the beginning, before
the menu comes up (so pause the appearance, not the disappearance), we
would have mac-like submenu drawing, which would be lovely.

> As you can see, I'm very much looking forward to this feature. 
> 
> Also, another thing. The TODO list states the item as "Improve submenu
> navigation", so another thing that frustrates me greatly in navigating
> submenus currently, and maybe someone else agrees with me: currently, you
> have to thread the mouse cursor through that little area between the
> right(or left) edge of the menu item with the submenu in order to hit the
> menu (David Every has a good diagram of this on his site). Well, GTK+
> currently makes the submenu jog down a few pixels from the top of the menu
> item it is born from. This makes the area even smaller. Both the
> Macintosh and Windows line up the submenu flush with the menu item that 
> is it's parent. I'm sure the argument could be made that once the submenu
> hysteresis is in place, this problem will go away, but still, I like all
> the help I can get. (Besides, it just doesn't look right to me). 

This should be user customizable, clearly.
I'll find out where this is set, move the magic number up to the top,
and leave a FIXME and TODO note for the people working on gtk
customization.

Thanks for your interest! With work, GTK'll have the best menus
around!

-- 
  -nils
Public key: http://www.fas.harvard.edu/~nbarth/pub-key.txt

PGP signature