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. ...
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 ...
Even though Apple recommended (and surprisingly still recommends) pickers for dropdowns, not even they use it anymore. Spoilers:
In both these cases, the "logic" would dictate to use a dropdown + picker. Apple chose a much better solution for their own apps.
Still, a whole screen to pick between "Female" or "Male" (pardon the binary example) seems ...
My initial thought is that I'd personally avoid attaching a chevron to the checkbox like you've got in your screenshot because it's an atypical design pattern and therefore pretty safe to assume that a (possibly significant) percentage of your user base won't be familiar with it and they'll have to work to figure it out, which means increased cognitive load, ...
There is a similar UI for managing exceptions in Visual Studio, which is fairly intuitive:
The key differences to the UI you have shown are:
Chevrons/arrows appear to the left of the top level checkboxes, making the control more like a familiar tree control.
The top level checkboxes are tri-state checkboxes so you can see if only all/some/none of the child ...
In this situation, I would not use a drop down until you need to.
Using a drop down with one option will be annoying to some degree because people will click on it and expect more choices but not find any. Also, people will be trained to not click on that drop down because its 'useless'. You'll have to somehow retrain them to look for the new options if/...
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 ...
Fulfilling user expectations is a fine goal, but it’ll only get you so far. Unexpected results are not themselves bad. Sometimes they are even delightful (“Surprise!”). However, unexpected things in a UI are a sign of a usability problem. To resolve conflicts between kinds of consistency, you need to analyze the situation for the impacts of violating ...
For any select list of over a couple dozen options, free-text search with autocomplete support is the only sane option.
This is a common pattern seen on real estate sites (Zillow, Redfin, etc) and travel sites (AirBnb, Kayak, any airline, etc.) Kayak shown below.
Fred Meyer (big-box retailer) has a 'Select Store' search box to solve this - requesting you ...
The only time you should use a dropdown where there is only one available option is: to stay consistent with pages that have many options for the same selection.
For example: You are shopping for a new pair of shoes and are currently looking at a style that has sizes 5-14 available. These sizes are displayed in a dropdown. You click on a different style ...
...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
The overlay is faster when picking neighboring values.
Selecting the next (or previous) value is useful when...
Making a font size a little bigger (or smaller).
"Trying out" each font in the list (one at a time) to find the "correct" one.
Changing the quantity when ordering a product.
Picking the correct option, after overshooting (with the mouse) and ...
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, ...
From an accessibility point of view, It is recommended that the event should be fired on mouse up rather than on mouse down.
This will be helpful for users with dexterity/motor disabilities, Who might accidentally click on the list without the intention to do so. So when the event is fired on mouse up, that will give these users a chance to cancel the ...
First I would add an information text beside the + button to let the users know how to use it.
What I would worry about is, when the dropdown list will hold a lot of values, it will be very laborious to find the wanted value. So many users will just add the value they're searching for without looking if this value is already there.
This could generate ...
Since I cannot see the harm in putting the currency symbol on all the values I would suggest the first option. It might help save an error if you have more than one drop-down with another currency.
Can you think of any reason why you wouldn't?
When clicking "Backup Media Library", should it select/unselect, or expand/collapse?
It should select/unselect. This is the default behavior and makes the checkbox more accessible.
If the expand/collapse behavior is tied to the chevron alone (my preference), is it too small for the user to click? Should I replace it with something bigger, like [...
You could try...
Allow the user free form text entry. As the user types a filtered list appears of items that match what the user is typing.
Pick a number of items to show that is reasonable. You can provide a scrolling list when more items are available, or just show a set number and require the user to continue to type in something more specific ...
For very long lists, it's better to use a different UX for mobile
Multi-select is a complex operation, so it's difficult to use the same interface for both web and mobile. You already recognize this because you've outlined two different layouts.
Your mobile design is problematic because:
It requires users to tap once to add an item, and then select items ...
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 ...
I wouldn't say there are guidelines as such, but most design systems provide an insight on how to use dropdowns. Here are a few examples:
Material Design: Exposed Dropdown Menu
IOS - Pickers
Sidenote, Apple generally doesn't like dropdowns, they take you to a whole other page with selections.
Microsoft Fluent Design Guidelines
Not exactly what you ...
If your question is whether or not to use the checkbox, I think it looks better and does have a better user experience with the checkbox especially the unconscious overview it gives the user while making multiple selections.
You should show them, but disabled or gray'ed out. If you are worried about confusion, you can make them appear disabled, but display a dialog if they are clicked.
In addition, if the user has UI options, make HIDING them an option.
Either way, I would still keep them on the internal MRU list, in case they become availible again.
A standard way of solving this is autocomplete. For instance, here is how it works in Jira.
User starts editing a field. There are options to accept/cancel the input:
User may click the down arrow and see a list of existing items:
Or they can start typing in the field and then it offers a list to autocomplete:
Finally, user may add their own value:
The best? Only testing will tell.
Going to both your examples, the second one is way better from an user point of view. See both dropdowns: one has a list of TLD and nothing else. The other, a list of TLD PLUS the price. And in the domain business, this is a huge difference since the newer TLD use to be way more expensive than the classic original TLD. ...