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.
If I saw that in an interface - I would assume only one item can be checked, especially before any had been selected. Only the wording of the title would indicate to me that multiple selection is possible. I think this design would lead to a greater than normal number of people choosing a single item rather than a selection of items.
I don't see the benefit ...
You're not supposed to leave radio buttons blank. They're allowed to be blank so you can avoid setting defaults as mentioned in the question about setting a default gender. You can't not pick a gender, it's a required field, though you can leave a "prefer not to say" etc. option; this is different than the user never touching the radio button, however. If ...
My first idea was the same as in Izhaki's answer, but later I thought of this, that seems to fulfill your goal and to reduce (at least a bit) the need of user interaction without drawbacks.
(EDIT: thanks to @dennislees for improving the color design for constrast. If it goes well with the rest of your UI, IMO this will improve the consistency of this ...
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 ...
I believe it should as the entire region in the eyes of the user is the "selection". Now, I think you can look at this issue from another angle which is...how do we remove the perception of a space?
One solution is to include a background surrounding the checkbox and label region. On hover over, the background could change color as well to further ...
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 ...
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 ...
There should never be just one radio button, as it breaks the user's expectations on how they work. Radio buttons are meant to allow selection of one and only one item from a set of several radio buttons.
If you really want to use radio buttons, you could either go with this approach:
() I like the following sweeties:
That depends on the context.
A checkbox that makes the user accept terms of agreement for example should be unchecked since its a critical decision which needs the users interaction to be legally okay.
On non-critical checkboxes you can pre-select them according to what most users want/need. If 80% of your users hit the checkbox you can pre-select that ...
This has been discussed in much depth in many other related questions (see right pane on this page). So I'll make it brief.
Toggle switches are anti-usability
Despite their relative popularity (eg, Apple use them as a standard interface control) toggle switches have an inherent state-action ambiguity; that is, it is unclear whether the label ('on' for ...
One way of making a selection task less tedious is by increasing the selection target size to the full image + text size (e.g., as in the attached mockup). This decreases the effort that goes into individual selection and can provide an appealing and easy to see overview on which books are selected. Additionally, you can distributed the 100 books over ...
Wrap the label around the checkbox. This makes it much easier to click the button.
If the label is separate from the control, then there is often a non-clickable gap between them.
<input id="click-me" name="click-me" type="checkbox"/>
download bmml source – Wireframes created with ...
Maybe you can try a mix of usual buttons (to have a big area to click on) and the usual radio/checkbox controls. I wouldn't totally remove those controls because then you'd have to add text descriptions like "Select only one." or "Select multiple."
You could also grey out the radios/checkboxes that they are just a subtle hint.
A checkbox should look like a box and not a circle. They are not check circles, after all. Subtly rounded corners, as others have mentioned, would be okay, but user interfaces have always represented a checkbox as a square and a radio button as a circle. The designers behind your examples are likely trying to be different, favoring style over function.
Yes - underhanded, but this is not a problem reserved for the web - it's long been an issue for print too.
A couple of years ago, the EU banned pre-ticked boxes on shopping websites in order to prevent such issues as unintentional purchase of insurance or optional extras when purchasing plane tickets, for example.
The legislation does appear to revolve ...
The only case where a checkbox should be marked "required" is if it must be checked, like when agreeing to legal terms.
For any other case, how do you determine whether the user has completed that checkbox field? It might be properly filled out by staying un-checked. Except for the specific case of agreeing to terms, it's important that your ...
Show the true state of your application
In your scenario it sounds like Scenario A - Example A is the way to go because it clearly indicates to the user which features are Active and allows them to turn off features that they aren't using. Instead of asking Which of these features do you have? simply show them what is active and allow them to turn some off.....
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.
Checkboxes vs. Radio Buttons - Nielsen Norman 2004
Radio buttons are used when there is a list of two or more options that are mutually exclusive and the user must select exactly one choice. In other words, clicking a non-selected radio button will deselect whatever other button was previously selected in the list.
Checkboxes are used ...
Martin, take a look at what jQuery Mobile has done with radio buttons and checkboxes. Here is a demo page:
jQuery Mobile Docs: Gallery of Form Controls
They give you two viable options that I think you'll enjoy.
Keep checkboxes and radio buttons looking the same but making them have a surface area that is larger and more clickable.
The new Apple iOS ...
A checkbox should be square. As Cooper, Reimann, and Cronin wrote in About Face 3 (emphasis mine):
Traditionally, checkboxes are square. Users recognize visual objects
by their shape, and the square checkbox is an important standard.
There is nothing inherently good or bad about squareness; it just
happens to have been the shape originally chosen ...
Double-click Checkboxes are …
… one of the most terrible ideas i've heard about in a while. Users expect a checkbox to be single-click. Period.
There is no problem with accidently clicking checkboxes:
Actions triggered by checkboxes should be instantly reversible per se. Thus, miss-clicking should be a non-issue, since a simple second click will restore ...
Typically even a tri-state checkbox is still to be treated as a two-state check box in terms of the user's interaction. The user should not be able to switch it between all three states - only between checked and unchecked.
It is only if the information that is related is not in either state that the box is 'displayed' in the tri-state.
What does it even ...
I'd prefer the option you called "positive statement". The reason isn't only consistency. The other reasons are:
Positive statement style is a great way to introduce the functionality of the application. So config dialog could partially play the role of software help and documentation. It tells to a user like: "I can do this, and this, and this...". The ...
Pre selection of checkboxes
Successful pre-selections can make interface more efficient and pleasurable to use. Sane default selections can reduce the amount of actions a user needs to perform.
Whether or not a checkbox should be preselected should be based on the domain context and business rules. Business rules will dictate whether something should be ...
You should definitely let users know if it's mandatory before letting them click a button and get frustrated because they couldn't proceed.
Things you could do:
Change the headline from "Please agree to the following:" to something like "To continue it is necessary to agree to the following:"
which if course is longer and you don't have a guarantee that ...
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 ...
Answer to your main question: This is legacy behavior left over from the desktop. This is how desktop applications did it for decades before the web came along. When form elements appeared in HTML, they just copied the behavior from the desktop. The original designers of the radio button probably couldn't have imagined how this control would be used over ...