It depends on the purpose of the dialog. A customer filling out his shipping information, for instance, would reasonably expect countries to be listed using the same language as the rest of the website. A customer on an English website would just be confused if he had to select "日本" to ship to Japan.
But when the dialogue is to change the country/language, ...
Use either Responsive Disclosure or Responsive Enabling depending upon the standards in the format you're working in.
Responsive Disclosure would mean first showing a radio button like this...
download bmml source – Wireframes created with Balsamiq Mockups
...and then revealing the additional option in the whitespace if the user selects no, like ...
Worked on a project with this exact problem. We needed a way for the admin staff to add attribute to products. Because attributes are used for search purposes, we need to ensure if that attribute type already exists, it should be selected instead of creating a brand new one.
We ended up using something akin to your first idea.
download bmml source – ...
The Apple OSX Human Interface Guidelines (2012) recommend a drop down if you have more than 5 options, while the Microsoft Windows 10 User Experience Guidelines recommend a drop down if you have more than 8 options. So, take the average and stay with radio buttons if you less than 6.5 options (shrug). You’re near the borderline (at least for one ...
I need to make it obvious to the user that it is a dropdown.
By making it look like a dropdown.
Don't make it so wide. The reason it doesn't look 'clickable' is because it doesn't look like a drop down because it's stretched across the entire width of the screen.
I would consider two things here:
Visual connection to action
Common standard implementation
To the first point - visual connection: If you see an arrow that points up, you expect something to happen in that direction. You will automatically look up, not down. So every action that goes to a different direction will feel alien, detached. So this argument ...
A button should show what will happen when it is next clicked - not point to something else.
When the button above a closed menu is clicked, the content will drop down - so the should point down (to where the content will appear)
When the button above an open menu is clicked, the content will move up into the button - so the arrow should point up.
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 ...
Microsoft does this in Windows Explorer! I noticed this on my Windows 7 work computer just a few weeks ago, and I can't stress enough just how handy it is (in certain situations)
The key here is that they made it exceedingly functional but it also stays out of the way until the user discovers it.
What a great question. As a general rule, it's good to flip positioning of iconography for RTL languages. So your bottom option, with the chevron on the left, is correct.
If you're curious, I'm basing this answer on lessons learned running as lead designer on multiple projects with the NYC DOE and NYC mayor's office, where all projects have to support 11 ...
This kind of UI elements exists and is used in many applications even if differently.
If well designed they are even more affordant than the usual radio buttons.
The thing is, because of this affordance they seem "auto selected" so there is no need of a validation like in your example. Therefore I would say radio buttons ...
The first idea failed field testing and variants failed usability testing
It sounds like we had the same idea as your option 1, and we implemented it. We were looking for a way to force users to search first without users realizing that we were forcing the search to occur. A variant of our first design actually tested OK with a small sample in usability-...
A dropdown list (or combobox) should already be a clear indication that you need to select an item from there, so wasting the first item by telling someone this is redundant and a poor idea.
The only times that I would recommend having some other text in the dropdown are:
when it is not essential to select an item
when you want effectively to select all ...
Arrows pointing in our reading direction (right or down) point forwards. Buttons should indicate what happens when clicked. The arrow on a dropdown button should point right or down as it indicates new content will be visible once clicked.
Once the dropdown has been opened, clicking the button again should close it. Therefore the arrow should point upwards ...
A single button should perform an action, and not act as a radio button. If you want buttons to act as radio buttons, you should use a segmented button.
There is established precedent for this in both mobile and web UI, so people are likely to already understand what they do. Additionally the design of segmented buttons shows that the buttons are related ...
My answer shows simularities with others posted here but I want to emphasize how important the right communication is.
Reconsider the used language to make the intentions clear. For example use create company to add some weight to the action or use the word new to emphasize the difference.
download bmml source – Wireframes created with ...
I recommend implementing some kind of searching functionality. Dropdown-search hybrid elements are quite popular and a good way to solve this.
Given your requirement:
Each status has it's own associated colour and would ideally be displayed in the list
Then we're not discussing if there should be a color or not, question is how to harmoniously display that color in a way compatible with Google Material Design?
Coloring the entire item is problematic:
It's not aesthetically pleasant.
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 ...
Setting is singular, so use it if you only have one thing to set.
Settings is plural, so use it when you have multiple things to set. This is likely to be the case most of the time, so when in doubt, use 'Settings'
Unless you can proceed without selecting (leave the field blank) one SD options, I would suggest you go with a radio button.
Your layout remains consistent if you are using the same input mechanism for similar tasks. Making it easy for the user to proceed quickly.
Radio buttons are faster (easier also in many cases) than using a drop down menu. The ...
Maybe you could separate the dropdown from the 'Group by' label, and align them at the two sides of the available space and - as others have already suggested - make your dropdow look like a dropdown.:
This way it spans over the width of the content (so it can serve as a header) while you have a recognizable dropdown.
And if it applies: you can introduce ...
It depends on what you want to do. :)
Use checkboxes (or other toggle buttons) if you want to provide for applying several filters at once. If you want to use them for single value, then listen to @AndroidHustle regarding manipulating them, and only use them for single, independent, boolean values.
download bmml source – Wireframes created with ...
In a scenario where the user has to select simple true/false or active/inactive states then I would really suggest that you use a checkbox control rather than a control which would feature redundant input, eg:
In a case such as this there is no reason to add additional input controls which provides the same result as a more simple checkbox control. Either ...
Go with check boxes for multi-select inputs.
It is a norm in implementation since the first GUIs and it a standard practice in UX too. Nielsen's article confirming the use of check boxes: http://www.nngroup.com/articles/checkboxes-vs-radio-buttons/
Checkboxes are used when there are lists of options and the user may select any number of choices, including ...
A drop down is probably not your best option here. To make this task clearly understandable a more suitable UI would be some form of dual list as in the example below: This does not only offer a selection mechanism but also a constant visibility of what has been selected.
Given that you have limited manoeuvre around the design i would suggest the ...
There're three cases that you have to be able to identify: yes / no / not-specified (i.e., user did not interact with this element). But if you pre-select yes or no then you won't be able to distinguish it from the not-specified case as you pointed.
I'd suggest to use radio buttons or a drop-down (as both options are mutually exclusive) without pre-...
There is a background issue here which is: Should the sub-menu open on click or on hover?
If you choose to display it on click, it is clear that you can only use OptionA (ServiceA, ServiceB, ..., All services). This works consistently for both touch and no-touch devices.
If you choose to display it on hover, some conflicts arise:
Will the user know that ...
According to the W3C, the default behavior of radio elements with no default control set to checked is undefined.
Radio buttons are like checkboxes except that when several share the
same control name, they are mutually exclusive: when one is switched
"on", all others with the same name are ...
Short answer: Use your second option, where each field has a neutral white color as the color is not classifing elements in the list.
Color should be used to give distinction with other elements from its context or to differentiate elements.
Think of the way links have color and not the surrounding text. For example (image source):
In the image above, an ...