Should a dropdown list be automatically closed when you leave current object and navigate to another, or should it remain opened until you open next dropdown list?
- Dropdown closed when mouse leaves
- Dropdown remains opened
-
113@DimitraMiha: "when the user goes to another object because that means that the user wants to do another action" - or they want the cursor out of the way to read the content of the dropdown.– O. R. MapperCommented Apr 21, 2017 at 11:11
-
71I can only say that I usually find it annoying when drop-down lists/menus close when the mouse moves out of the menu. For one thing, I seldom move the mouse (or in my case, trackball) in a perfectly straight vertical line, so the cursor may wander outside the menu going from A to B, closing the menu and making me start all over again.– jamesqfCommented Apr 21, 2017 at 19:00
-
103Fast close on mouse-out is one of the most user-hostile ways a dropdown can act. Other people here are being far milder about this than I would be. There are other ways to let a user conveniently close a dropdown.– VeedracCommented Apr 21, 2017 at 22:59
-
22Close on mouse-out could even be an accessability issue… mice have high point accuracy but low path accuracy, which is why they aren't usually good for drawing. Even after decades of constant use i still accidentally close these things all the time.– WeaverCommented Apr 22, 2017 at 7:50
-
7@Poly, same as the right-click menu: click anywhere else. I don't think many users will have a problem with this.– user69458Commented Apr 22, 2017 at 15:53
|
Show 15 more comments
13 Answers
For consistency, the behavior should be based on the calling action; click or hover.
If you are opening the dropdown on click, let the user toggle and close it, or close the previous dropdown when user clicks on another thumbnail.
If you are opening the dropdown on mouse-over, close it on mouse-out.
-
103As an addition to this, I would suggest having it fade out allowing recovery before its gone. I can't count the number of times I have slipped off a dropdown multiple times in a row. Commented Apr 21, 2017 at 15:39
-
43I would suggest caution for fade out depending on what the dropdown covers. I recall being frustrated waiting for dropdowns to disappear so I can get at what they are covering. And if the timing isn't quite synched to the rendering having it pop back up after I believe it is fully faded out, and then having to wait again. Commented Apr 21, 2017 at 16:33
-
78Simply don't use dropdown-on-hover! Those things are awful! Showing options on hover can work, but you shouldn't be asked to navigate a mouse maze to make them show up!– VeedracCommented Apr 21, 2017 at 23:01
-
12
-
6One addition to this; if you're going to show/hide on hover, make sure your detection area is reasonable, especially for the mouse-out event. In particular I've encountered some very poor implementations where if you weren't extremely careful in mousing through the caret at the top of the box the entire menu would disappear on you when you went to click on one of the items. If you don't know how to have a detection area that's larger than the menu itself, don't show/hide menus on hover.– arothCommented Apr 24, 2017 at 3:30
The answer to this question is part of a more general UX rule: moving the mouse (without a button held down) is not input, and applications should not respond to it by taking any nontrivial action. Trivial actions include things like adding/removing underline, changing color, or performing a small, spatially isolated animation to indicate clickability. Showing or hiding information/UI elements is nontrivial, and really annoying to users who move the mouse cursor (which might be oversized for accessibility reasons!) off the top of the text they're trying to read so that they can read it.
Added (since the comments seem to be generating debate over what is "trivial"): My intent is that an action/reaction to mouse movement is trivial if:
- Omitting it entirely would not remove information or limit the ability to interact with the interface, and
- Presence of the action does not disrupt or interfere with ability to read or interact with the interface.
Mouseover dropdowns/menus (and also tooltips) fail both criteria if they can't also be activated by clicks, and fail the second one either way unless you arrange for them to appear in a special area where they don't obscure other content.
answered Apr 21, 2017 at 15:49
-
5This isn't quite a blanket rule. Ever heard of mouseover text?– WildcardCommented Apr 22, 2017 at 2:34
-
7Well, I disagree strongly. It's a way to find out more about an unfamiliar UI without doing something (clicking) that you can expect to trigger some actual action. However, it should have a reasonable delay; most do. Check the mouseover on SE itself. And note that when you enter "mouseover mode" there is no delay on switching from item to item. This is great UX IMO.– WildcardCommented Apr 22, 2017 at 2:41
-
5Survey more newbie users. I work with such a lot, and I think you'll find that they hover over a button wondering if it's the right one, and look at the cursor, so mouseover text informs them right where they need it. And that most of them have never noticed the link preview area in the browser, or don't know what it is. Newbie users don't necessarily see every section of the screen the way advanced users do. They only see the narrow part they're looking at. Toolbars seem to be a bewildering array of random icons.– WildcardCommented Apr 22, 2017 at 2:46
-
15@Wildcard: Actually, I would classify tooltips (which always have a delay before they show) as trivial actions. They are hints, and nothing more, and if you rely on them for anything more than a non-trivial reason, then you're doing something wrong. (I would also say they're great UX, because they're the ultimate in contextual help: they show up exactly when users need help, but stay out of the way otherwise.)– user69458Commented Apr 22, 2017 at 16:04
-
3@FighterJet - You may classify tooltips that way (and I might agree with that classification), however according to how this answer is written that classification is incorrect. Tooltips will often obscure text and other components on the page, and thus fail the "does not disrupt or interfere with ability to read or interact with the interface" test suggested in the answer. Which means (according to the answer) that tooltips should only be activated by click. Which I think is awful UX, and a good example of why this answer is just plain wrong.– arothCommented Apr 24, 2017 at 3:43
I honestly think that hover menus are bad UX entirely.
I suspect the only reason they exist in the first place is that they are easier to implement in pure CSS, so the developer can get away with something the user doesn’t necessarily want.
Here are some points to consider:
- Most operating systems wait for a user click before activating a menu. The hover menu goes against a well established pattern.
- The operating system has menus in a separate part of the window, where their behavior is anticipated. Hover menus are part of the content, and compete with the rest of the content.
- Users routinely use a mouse without any intent, or simply to follow their eyes. The hover menu disrupts this behavior, often obscuring content which the user was looking at.
- Touch devices, at this point in time, do not include a true hover action. Hover menus represent a different behavior between desktop and touch devices. In fact, they often behave as click menus in this context.
- Non-sighted users will not experience the hover menu at all, which is a small mercy.
While a web application is not exactly the same as a desktop application, there are conventions and prior experiences, as well as expectations, to accommodate.
Click (or touch) activated menus are, these days, easy enough to implement with a few lines of CSS and (non-jQuery) JavaScript.
The short answer is a dropdown should be activated deliberately and deactivated deliberately. This is not with mouse move, but with a click or a touch.
-
2You can actually do clickable dropdowns entirely in CSS and HTML: jsfiddle.net/pq0mxvj2.– Yay295Commented Apr 24, 2017 at 17:44
-
3@Yay295 The problem is that
:checkeddoesn’t work with Certain Legacy Browsers™. You can also use:activebut that doesn’t work well on touch devices.– ManngoCommented Apr 24, 2017 at 21:00 -
1
:activeelements are only active while you are clicking them; it doesn't work well on any device. Chrome and Firefox have supported:checkedsince version 1, and IE since 9, meaning less than 0.5% of people browsing the web are unsupported.– Yay295Commented Apr 24, 2017 at 21:18 -
1@Yay295 not that that doesn't mean 0.5% of your users would be unsupported.– TimCommented Apr 24, 2017 at 22:20
-
2Your list need one more point: "It's super, super annoying when the drop down disappears and have you have to align and move your mouse juuuuuust right to actually click anything in the drop down/pop up."– jpmc26Commented Apr 25, 2017 at 3:47
I agree with DPS's answer, however I'd opt for explicit behaviour - thus clicking to open and clicking (or pressing Esc) to close.
Why not "on-hover"?
If the user opens the dropdown and makes a more generous mouse move (move away the cursor to read all the options) - the menu disappears increasing the annoyance.
There is something else I'd like to mention - when the dropdown appears, it is placed bottom-left to the mouse cursor. In my opinion it should be placed bottom-right. The user follows the mouse pointer and in majority of cultures we tend to process the information from left to right. If the user is focused on the mouse pointer, they expect the menu to appear to the right, so their data processing flow is not disturbed.
Having the above in mind - if you go for "on hover" option, it is very easy to move the cursor away from the dropdown and by this close it.
-
1I would have the dropdown appear to the right, just so it doesn't completely cover the object it's applying to. Commented Apr 21, 2017 at 15:36
-
Or move the menu icon to the left so the dropdown still covers the object it applies to. Commented Apr 21, 2017 at 15:41
-
1The other benefit to explicit behavior is, of course, that it works on touch-only devices (think phones and tablets). We do not know enough about the OP's scenario to know if that matters, but I like to keep it in mind whenever possible.– DocMaxCommented Apr 21, 2017 at 19:29
-
Good point about placement, +1. On both Mac and Windows context menus (for right clicking) appear bottom-right to the mouse cursor, unless you are right up close against the right hand side of the monitor—in which case Mac puts dropdown bottom-left from the mouse cursor, and Windows puts dropdown bottom-right as far as they can so it ends up flush against the right side of your screen, with the cursor near the center of its top. (I think the Mac behavior is cleaner, personally.)– WildcardCommented Apr 22, 2017 at 2:33
-
@Wildcard: the Mac behaviour when cursor is near the right-hand edge of the screen is application-dependent. E.g. (at least in OS X 10.9, on the computer I’m using now) the Finder gives what you describe as the Mac behaviour, while Safari gives what you describe as the Windows behaviour.– PLLCommented Apr 22, 2017 at 10:22
...Or you can consider changing the design altogether. Personally I think it's not a good idea to hide functionality under three dots.
Show actions on hover
You can remove click/hover altogether by showing actions straight on hover. I'd argue it's better since you save the click (I'm not showing move/rename for brevity).
Show actions in the main screen
If design allows, actions can always be visible on the main screen. If you think that icons are vague, you can add tooltip or change layout to show icons with labels.
-
For simplicity, you can allow renaming by clicking on the title. Commented Apr 23, 2017 at 15:46
-
You might consider adding a way for the user to close the drop down. This way there is no confusion on how to close it and no annoyance of accidentally closing it by moving the mouse out of the area.
-
2Nice, simple and usable. No gratuitous code. Don't forget that the average user doesn't care about how clever things are, they just want them to work. Commented Apr 25, 2017 at 6:22
-
3I would agree with this if it didn't look so bad. Not trying to knock on your design at all because it's not your fault; the
xjust looks so out-of-place in this menu for some reason. Commented Apr 25, 2017 at 17:05 -
@ChaseSandmann it only looks out of place because of the colour its been given in the example. But I guess that was to highlight it as an addition rather than to suggest actually making it that colour. Make it a more subtle grey and it would look fine.– SimbaCommented Apr 27, 2017 at 13:15
-
I went ahead and edited the close button to mesh a little better with the given example. Commented Apr 27, 2017 at 15:58
-
This looks a bit like a delete option of the first item in the list. Commented Apr 28, 2017 at 6:30
I happen to find that behavior quite annoying, especially with nested menus, on YouTube on a HTPC. The remote mouse is easy to get off track and wham I have to start over. Anyone with less than perfect dexterity will find this to be annoying.
Please don't make the precise path of the pointer a necessary part of the UI. Some people have mobility issues, some have less than idea pointing devices, some are in a moving vehicle, etc.
-
1+1 for the mobility issues. Don't expect all users to be able to produce perfect pointer movements Commented Apr 25, 2017 at 23:05
Apart from what DPS answered, which talks about consistency, I would suggest you go with the click instead of hover. It seems like you have a grid layout, and am sure you don't want to annoy your users popping up the action menu when they move the mouse over these grid items.
It is better to keep it explicit, only when the user tries to click on the action button. One more thing you can do here is that change the icon so that it is clear that he needs to click back to toggle it, something like:
Make sure that it should collapse if user clicks elsewhere on the page (this also includes the users who try to click on the action menu of another image)
Another thing you can try out is to have common action buttons and let the user select the images on long click. The only thing which might be an issue over here is the move option. I'm not sure what functionality you have in place there(i.e is it draggable, click sort and so on)
You can smoothly animate these icons once the user selects >= 1 image in the grid.
I'd say: click on ... to open, click on anywhere but the dropdown menu to close. Once we click the open button, we tend to move away and going back and pressing it again can be exhausting. There's also a danger of pressing the first item on the dropdown list. I've seen the open/close on hover performing so badly that I think shouldn't be an option. What happens is that the dropdown disappears once you start moving from the ... button towards the menu.
- Mouse-over,mouse-leave events to open-close a drop-down menu is in general not a good idea.
- Preferably click or touch events should open-close a drop-down menu.
To be more specific... In the example you provided in your question where the drop-down opens above an image element one thing you could do is lower the opacity of the menu (e.g. to 20%) if the user moves the mouse out of the menu-box. In that case you will have in your hands a partially transparent menu so that the user could still view the element below the menu.
Immediately closing such a list even if the mouse is a pixel out of its region for a split second - especially with dropdowns where the region changes due to submenus (which also means your user has to repeat a whole navigation chain in the worst case) etc. - tends to be very susceptible to spurious mouse movements (aggravated if: bad mouse skills, a mouse set up for speed not precision, a vibration-rich work environment, small size of UI elements).
Letting the opened menu stay forever can end up in a user being confused about how to close a menu that is covering content or other UI elements.
Delays and some hysteresis between activation and deactivation regions will probably follow the principle of least astonishment best...
Mobile or not?
Some years ago, when the only input was using the mouse (or pressing the Alt key... nobody really expected that) a mouse hover was a good option.
But not anymore.
The minimized design you are using implies that the design is intended for a small device, so there is no real mouse hover.
My opinion is click to open and click to close.
A timer?
But you also could include a timer. If no input is made in some seconds, that menu could collapse.
Some problems with the mouse out
Evident problem with a mobile device.
A desktop user could have issues, for example with a defective mouse that moves the mouse pointer like crazy (I had some cheap mouses sometimes)
Some laptop pads can be tricky to use. A mouse hover/out needs more skill from the user.
One additional problem thinking on a mouse hover - mouse out approach is that the user could need to move the pointer for some reason, but still needed that menu open. A screen capture? Working in another window?
-
2I disagree on the timer idea. "If no input is made in some seconds, that menu could collapse". This will inevitably lead to (1) the menu closing before some users could read all the options, (2) the menu closing right as the users was about to click an option and instead the user clicks the item (3) there's no clear reason on why the menu is closing. Commented Apr 25, 2017 at 23:08
Once mouse leaves, everything goes away
This is simple logic, and working with prototypes would show it immediately. Using your same caffe images, we can do a simple analogy. Let's say you go to caffe1, then open the menu and order something. You leave and go to caffe2. Where at it.... would you expect to see caffe1 menu or caffe2 menu? What would you think if you see caffe1's menu instead of caffe2's?
Well, as tou can see the answers are obvious, and they're based in layout construction principles. They not only apply to your example, but they apply to everything. Think of a terrain (layout) where you build a house with different rooms. Some might be similar, but they all will have special characteristics and possibilities: you'll have a kitchen, a bathroom, a dining room, a laundry, etc. All of them with different possibilities. You'll be able to cook in the kitchen, but you won't be able to do it in the laundry.
This is known as plane and dimensions building, where you have different planes and different dimensions which are related to physics and how we perceive the world around us (hence, while it only applies to your specific case in a tangential way, it includes time dimensions)
Material Design uses this metaphor of sheets of material with dimensions and depths (although contrary to popular belief, they didn't invent it). And it's really easy to implement: simply start with a blank sheet of paper. Then add elements as needed. Use post-it or cut from other pieces of paper. You'll create prototypes where you'll be able to see how each element connects, and more important, how they doesn't connect.
Hover vs Click
If this is responsive, go with click, bar none. There's no hover behavior on mobile, so building hover based behaviors is a waste of time. However, if this is adaptive, you can have a hover behavior for desktop (better for discovering) and click behavior for mobile. However, click to open and click to close is not needed, it's more effort and friction with no gain at all. Just do this:
- Desktop (adaptive):
on mouse leave, close menu. - Mobile (responsive):
on click (menu2), close menu 1
This way you save a click and avoid to have unnoticed menus open when you're in a completely different property
-
5The problem with your analogy is that moving the mouse does not signal intent to perform an action like walking between rooms does, and that while using the mouse, it has a precise point, but an imprecise path. So if you accidentally wander out of the menu a pixel or two while going to click a menu item, then bam, it's gone.– user69458Commented Apr 22, 2017 at 16:10
-
-
@FighterJet, if you're over an object, you're over an object. If you're not, you're not. That's precisely the idea of on_hover. If you move away, you're doing an explicit action to move out. Otherwise we'd be in an scenario where every hover behavior should be permanent "just in case". All this being said, do a Google search for mouse hover intent and you'll find how to solve even this "problem" you mention (keep in mind I didn't go deep into implementation since this is not an implementation forum)– DevinCommented Apr 22, 2017 at 17:48
-
@eckes, hence why I mentioned different scenarios for desktop and mobile (which obviously don't use a mouse)– DevinCommented Apr 22, 2017 at 17:49
-
3One of the things you need to consider is people with physical limitations like shaking hands, that need to place the pointer (through involuntary and/or imprecise movements) and then can press a button. If the menu goes away due to those involuntary movements, the menu is unusable for those users. Even 'regular' users can move the mouse when they sneeze, or if there's dirt in the mouse's ball or optics. Commented Apr 25, 2017 at 23:12