1 Posted by Dante on 12 May 2005 | Permalink

I'd say A, D, or E. Though make sure for D that the time isn't too long. 3 seconds max. Otherwise you're obscuring content for the user.

2 Posted by Stuart Colville on 12 May 2005 | Permalink

I would go for C maybe with a touch of D but not as long as five seconds. I would reckon on that being the most common and expected set-up.

3 Posted by Craig C. on 12 May 2005 | Permalink

A and C, with a slight delay on C (a second or less, just long enough that the menu isn't lost by a tiny twitch, not long enough that it lingers annoyingly).

4 Posted by Thomas Goyne on 12 May 2005 | Permalink

A, C (with a delay, preferably), and E. Absolutly not D. D would result in the following: User opens submenu. User begins reading submenu. Submenu disapears before user decides on option.

5 Posted by Glen Murphy on 12 May 2005 | Permalink

I much prefer A with 'if user clicks anywhere outside the menu', and no 'disappear after delay'. It's the same way Windows menus work.

6 Posted by Fuzztrek on 12 May 2005 | Permalink

A & B: the focus has changed; this new link should not be confused with the old one regardless of whether or not it contains a submenu.

C & D: The menu should fold in after a certain amount of time only when the user has moved his or her mouse off of the menu in its entirety. It should fold in instantly if the user clicks outside the menu in its entirety. I very much dislike menus that suddenly disappear simply because I couldn't read their dozen or so items in 2 seconds.

E: To show the user that something has happened, the menu should fold in.

7 Posted by Mark Kawakami on 12 May 2005 | Permalink

I'll second (or third or whatnot) A and C with slight delay. However, regarding A, I find it's often the case that when moving from to the submenu, users frequently inadvertently mouseover another menu item that causes the submenu to fold-in (and often another to fold-out). This happens most often when the destination is sharply diagonal to the originating menu item. I notice the way Apple handles this in the menu bar is to ignore the mouseover if the mouse is traveling about 45 degrees or toward the submenu. In other words, if the mouse is traveling more vertically than horizontally (in vertically oriented menus like the menu bar), mousing over the next menu item activates it and closes the submenu. Otherwise, the submenu remains open. In a webpage, emulating this behavior can be computationally expensive, I imagine, but it really does a lot to prevent the annoying accidental menu closures that are so often encountered on Windows and other OSes (and many, many webpages).

8 Posted by Paul Strack on 12 May 2005 | Permalink

How about onmouseout? In particular, keep the menu open for as long as the mouse is over (a) the original link or (b) the submenu, but close it when it leaves either of those two regions. I admit this would work best with menues that expand down rather than to the left.

9 Posted by Roman on 12 May 2005 | Permalink

When the user mouses over another link, regardless of whether the new link contains a submenu. Perhaps, this is what you mean by C.

10 Posted by Jim Ley on 12 May 2005 | Permalink

Consistent with the settings in the Window Manager. (either explicit where it's configurable, or implicit where not).

This is currently impossible to know in a web-application, one day, hopefully not. The choice then is if you use your own easy to write safely convention or attempt to mimic your likely most popular - which would be C, unless you're using the keyboard to open the submenus.

11 Posted by Jonathan Perret on 12 May 2005 | Permalink

What I use myself :
1) When the user *clicks* anywhere outside of currently folded-out menus, all menus fold in.
2) A menu folds in if the mouse is in a position that implies another menu should fold out, BUT only after a timeout (300 to 500 ms seems to work well) ! In fact, I always use a timeout before folding menus out, even when there is no previous menu open. This avoids the annoying effect of menus folding out whenever you cross the site's menubar even if it's just to reach the browser's buttons.
The fact that timeouts are absolutely required for usability reduces all the "pure CSS" menus out there to an interesting hack but not a professional solution, IMHO.

12 Posted by David on 12 May 2005 | Permalink

A is good, though (like most others have said) there needs to be a timeout.
B seems a bit odd, and I can't picture a use for it, really.
C, but it needs a delay.
D would be really annoying, especially for longer menus.
E seems to be a subset of what I would (and others already have) suggested for F: If the user clicks outside of the menu, regardless of whether it's a link or not. I'd also add in the user tabbing to something that's not in the menu for those who're using the keyboard instead of the mouse (these are keyboard-accessible menus, right? ;-)
This is probably the only instance where there should not be a delay.

13 Posted by paul on 12 May 2005 | Permalink

A, B (both with a slight delay) and E. The reason it's the way menus work in windows, and most people know windows.

14 Posted by Peter Siewert on 13 May 2005 | Permalink

I'll throw my vote in with Glen Murphy and Jim Ley above. Users want consistencey. Make the menus as similar to Windows as possible (or any other OS for that matter). A different menu fold in style may be cool for, like 1 minute, then they will want to go back to the tried and true method refined through the ages.
Re-inventing the wheel is (almost) never a good thing.

15 Posted by Tom on 13 May 2005 | Permalink

C. Both A, B and E also make "the mouse leaves the submenu."

I dont like the idead of D at all.

16 Posted by chris on 14 May 2005 | Permalink

C. (As others have stated, C pretty much covers some of your other options naturally.) The submenu should fold in anytime it is no longer the center of focus. Of course, there should be a constraint on this. For example: D. If I accidently let my mouse go out of the (possibly) small submenu, I don't want it to disappear immediately. So a timer, maybe 2 seconds, would be good to allow me to get back to where I was before losing the menu.

17 Posted by Frenzie on 17 May 2005 | Permalink

Comment 16 is the behaviour Windows has by default, which I consider a good behaviour as well.

18 Posted by Vesa Piittinen on 17 May 2005 | Permalink

Frenzie: not true, because in Windows the submenus do not disappear if you keep mouse pointer outside the menu area. So it would be Windows default + automatical disappearance when not inside submenu area.

19 Posted by ppk on 18 May 2005 | Permalink

The clear votes were cast as follows: A 8 votes, C 7 votes, E 4 votes, user clicks outside menu 3 votes, B and D 2 votes, C with delay 1 vote.

I haven't been very clear in options A and B: for both options I meant other links in the main menu, and this has been standard behaviour of foldout menus for as long as they exist.

I like the suggestion "user clicks outside menu", and I'll probably implement it myself when I write a new foldout menu.

My conclusion is for the moment that A and B should be implemented for historical reasons, C should be implemented because people feel it's a good idea, D should not be implemented, and any click outside the menu (which includes E) should also be implemented.

This means there are plenty of ways to close the foldout menus, which I feel is a good thing, since one user will expect one way and another user another way. If we implement all these ways, most users will be served.

Thanks for the feedback.