Depends on whether the question is mandatory. You need radio buttons if you want to be sure that a user answered the question, as with an empty checkbox you'll never know whether a user just forgot this question.
There is no single proper answer but the control depends on the context.
Checkbox is suitable to minimize clutter but its use is limited for cases where described choice has also clear opposite meaning (without need of mentioning it) :
[X] include subdirectories
Radio buttons are suitable when making something more explicit or if choices need separate ...
You don't need to make different appearances for these components.
Your case is similar to well-known toggles in a toolbar of text processors like Word.
These font settings toggles act like checkboxes:
And these Word’s alignment controls act like radio buttons:
Note, they look identically and it doesn't produce any confusion or difficulties because in our ...
It depends. How often do your users see this form / section / settings?
Frequently used, long session applications give users a chance to remember how controls work, especially frequently used ones.
Part of this has to do with Application Posture.
A sovereign application is a program that monopolizes the user's attention for long periods of time.
I would use the checkbox, because:
it is visually concise (vs. radioboxes taking more screen space)
it is the bare minimum necessary to get the job done
it is a classic UI widget and people are familiar with it (though this applies to radio boxes too)
a paper version of the form can look the same (though some paper surveys use radioboxes)
Radioboxes would ...
If you really need to cover all the use cases:
Checkmark won't work because it can only cover two cases.
Radio buttons should cover it, but you are missing the third option. Something in the line of "I would rather not say." Because the current setup would break if you accidentally selected something (but by the look of it you probably support unchecking ...
I suggest to add a top level selection between filter X or boosters using radio buttons. Then a secondary level underneath Boosters where they can be selected using checkboxes. If the Filter X radio button is selected, disable the Booster checkboxes.
Depending on whether you want a clear option to have neither Filter X nor Boosters you could add another ...
I think your designer colleagues are right.
If I now look at the options, I have straightforward an idea how I can interact with them and for what they are used.
Using the squares for checkboxes and circles for radio buttons are very old, common and recognizable for most of the users. So, it simplyfies your problem in this case.
The checkbox is used to select or affirm a choice. The question "Do you have...?" is not offering a choice so a checkbox does not apply to the question. It even appears to select the question alone.
So a choice must be offered--yes or no. Then use the checkbox for choice selection.
See the Gestalt principle of Proximity: If the choices of horizontal radio set appear aligned too far apart, they can start to form 'groups' as columns instead of rows.
There's not necessarily a hard metric, but the general principal of proximity is:
The principle of proximity states that things that are close together appear to be more related than ...
@hsan 's comment on the question is important: if you need to be sure that the user has truly intended 'No' as their answer, you need them to actively make a selection, so the form is not submittable until they have made it.
For this, a select control with an disabled first option of 'please select' works well: https://codepen.io/anon/pen/LaZzzP
For your particular case it sounds like you need to add a third "N/A" option that is selected by default.
With regard to use of checkboxes vs. yes/no radios, I think checkboxes work better for situations where fields tend to remain "as they were" when the user first entered the form.
With proper grouping by the UX designer, this allows ...
I would go with "Remember" instead of "Save". The data is being saved, but so is the current comment. "Remember" has the connotation of "make it easier for me the next time".
Remember my name and email for future comments
I feel like sometimes just a little bit more text can be surprisingly effective.
You can simply tell people how many choices they have.
The left could say "select one of the following" while the right would be "Any of the following".
Excuse the unfitting font and size, just quickly did this in Paint. The font size of the second line should be the same or ...
As many other answers have said, it depends on the context
I would like to add though that it depends on not just the question you're asking but also how much you want the user to think about the question and their response. A radio box requires some action to move on while a checkbox can be skimmed over.
As DenR89 says, you can never be sure if a checkbox ...
Neither one is correct.
Radios and checkboxes are both designed for lists.
Therefore they would be used in a case like this where there are multiple adjective (numbers/quantities) or noun (object 1, 2, 3) options asked (at least two items).
Which of the following do you have?
- Whatever 1
- Whatever 2
- Whatever 3
The difference is that radios limit your ...
User should only be able to select one single option
(o)Duck ( )Goose ( )Avenging Condor of Death
NO answer is not an Answer. Once you select (click on a radio button) one of the 3 options in the previous example, you can only change your selection, not unselect.
User can select multiple options
[ ] Swiss ...
I suggest to clearly seperate Boosters and Filters if there are not compatible.
Here are 2 ideas :
with a tab system that force user to choose one group
Separate vertically both categories and mentioning it is an OR choice
I agree with Joao's layout suggestion, because it places related options closer together (think "Gestalt Law of Proximity"), so the perception of grouping is stronger. The vertical layout also make it easier to scan the options' labels, particularly if the lengths of the labels differs quite a bit.
As for the tooltips, I ran into a similar issue in ...
Revealing/Hiding the Select All checkbox will not work for tablet/phones as mouseover do not exist. Additionally, the first time user will have a tremendous disadvantage of NOT knowing to look for the SELECT ALL.
Another alternatives/suggestions: add a SELECT ALL as the first choice in each list.
A little bit of column A and a little bit of column B.
Standards are difficult to change especially when you have to work with multiple companies and browsers. With every change, you have to ensure browser compatibility for all available versions for all available browsers, you have to consider accessibility, touch behaviour etc.
As technology advances (...
That NN/g article is correct, and the answer to your question is, Yes! :)
As also stated in, say, the Switch section of the Material Design Guidelines, the key behavior of a switch is that "[w]hen a user toggles a switch, its corresponding action takes effect immediately."
Every time I've discussed this aspect with fellow Ix designers, we agreed that "...
I think in this situation it would be better to use comboboxes:
download bmml source – Wireframes created with Balsamiq Mockups
This makes the association between the labels and options very clear and makes it really easy to see which options are currently selected.
The downside is that changing an option now requires two clicks instead of one.
For this example I would refer to the law of proximity
"Objects that are near, or proximate to each other, tend to be grouped
A more in depth look at this law and how it is applied to GUI you can see on Nielsen Norman website
"When buttons, drop-downs, checkboxes, or other actionable GUI
elements are too far away from the objects they ...
Based on some of the basic rules like "Logical objects should be grouped together", IMO first option is lot better.
In second option - if someone wants to deselect one of previous selected checkboxes one must count which one is it in the list.
If you take first option, and place a bit of additional margin between groups (group = checkbox + 1 input ...
Most normal users don't know the difference between a radio button and a check button. At the most, they sometimes get upset when you can't activate multiple radio buttons where it would make sense.
Doing without a visual difference won't confuse a single user - they will see that in some cases selecting one thing removes the other selection, and in other ...
For 3, all you need is another option called 'Others' or 'Unspecified' as a child. And keep that unchecked while the rest are selected. There is no harm in adding a few additional options if those make sense. At the heart of it all, the tree structure should be clear to the users.
Including a fourth state is definitely not recommended because no one will be ...
If the number of top-level sections is three, or at least reasonably small, you can use a different layout:
The subsections will be rendered under the corresponding top-level section, so it expresses the hierarchy clearer.