« There must be 50 ways to close a popup: menus, dropdowns, tooltips, palettes, dialogs, and more | Main | From MacPaint to FiftyThree's Paper: Someday all our apps will be this great »

April 03, 2012

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451fb6769e20163037a414a970d

Listed below are links to weblogs that reference Make web menu bars more usable: open a menu on hover only if another menu is already open:

Comments

Account Deleted

There is another subtlety which is sometimes overlooked. If the user presses the mouse button over a menu title, it needs to expand immediately, without waiting until the user releases the button. After that, with the button still pressed, the user must be able to “riff” through the menu (with currently hovered item highlighted) and releasing the button over a menu item must activate it.

All standard Windows, GNOME, KDE menus support this usage. As far as I know, in early Apple interfaces it was the only way to use pulldown menus.

Google Documents does this right. Atlassian Confluence does it wrong.

Jan Miksovsky

yurivkhan: Ack, you're right! That would be a bit of UI history which *I* had forgotten too. I guess I'd long since gotten used to Windows' support for riffing with the mouse up, and by the time I went back to the Mac, they'd picked up that behavior too. Thanks for pointing this out.

Rewiring the QuickUI MenuBar control to support mouse down riffing seems like it would be quite hard. Once the user has moused down over a DOM element, I believe it captures the mouse, yes? Which might mean that tracking the mouse over different menus and menu items would essentially require writing a new hit-tracking library to calculate what element the mouse happened to be over. This seems like a colossal amount of work, more akin to implementing drag-and-drop than normal menu click handling. If that's the case, I'm even more impressed by the Google Docs menus than I already was.

The comments to this entry are closed.