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
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.
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:
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.
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:
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.
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.
I agree with DPS's answer, however I'd opt for explicit behaviour - thus clicking to open and clicking (or pressing Esc) to close.
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.
...Or you can consider changing the design altogether. Personally I think it's not a good idea to hide functionality under three dots.
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).
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.
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.
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.
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...
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.
But you also could include a timer. If no input is made in some seconds, that menu could collapse.
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?
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.
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:
on mouse leave, close menu.
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