On Checkboxes, Switches, and Radio Buttons. That Stuff.

I’m gonna try to section this off, differentiate, and summarize each (that is what I learned about each). I’ve learned that doing this helps me learn, and in a way my teacher-self kicks in where I get this sense of gratification if I can teach someone something :).

I read a few articles about checkboxes, switches, and radio buttons. In this blog/article I will be using several quotes from these readings, as well as paraphrasing things on what they said.

Article #1: “Checkboxes vs. Radio Buttons” by Jakob Nielsen. So the focus here is going to be checkboxes and radio buttons.

Firstly, Nielsen uses a visual example to illustrate a few points. This is an image he uses:

He follows up by saying, “The erroneous use of checkboxes where radio buttons should be. Because the two choices above are mutually exclusive, the page should present users with radio buttons, which restrict them to selecting exactly one option.” This is mistake #1.

Basically when we use radio buttons, you can only choose ONE option, not many. That’s not the same with checkboxes. With checkboxes you can choose several options. In the above example it seems that you can select both options, even though they’re the opposites of each other. That’s very contradictory and confusing.

The 2nd Mistake that the author explains is how the two answer choices seem to be their own things, but that shouldn’t be the case. They should be next to each other, grouped together, thus presenting an easier selection and a better usability experience.

“The recommendation from user testing of e-commerce sites it to leave the checkbox blank by default, so users must actively click it to opt in for further messages.”

When to Use Which Widgets?

1. Radio buttons. [W]hen there is a list of two of more options that are mutually exclusive and the user must select exactly one choice.
2. Checkboxes are used when there are lists of options and the user may select any number of choices. Each checkbox is independent of all other checkboxes in the list, so checking one box doesn’t uncheck the others.
3. A stand-alone checkbox is used for single option that the user can turn on or off.
4. Use standard visual representations. A checkbox should be a small square that has a checkmark or an X when selected. A radio button should be a small circle that has a solid circle inside it when selected.
5. Visually present groups of choices as groups, and clearly separate them from other groups on the same page. A list of radio buttons must always appear unified.
6. Lay out your lists vertically, with one choice per line.
7. Use positive and active wording to checkbox labels, so that it’s clear what will happen if the user turns on the checkbox.
8. If possible, use radio buttons rather than drop-down menus.
9. Always offer a default selection for radio button lists, such as ‘none’ or ‘other’.
10. Because radio buttons require exactly one choice, make sure that the options are both comprehensive and clearly distinct.
11. Let users select an option by clicking on either the button/box itself or its label.
12. Use checkboxes and radio buttons only to change settings, not as action buttons that make something happen. If the user clicks the Back button, any changes made to checkboxes or radio buttons on the page should be discarded and the original settings reinstated. The same guidelines obviously holds if the user clicks a cancel button.

“Following design standards enhances users’ ability to predict what a control will do and how they’ll operate it. When they see a list of radio buttons, they know they can only select one. Employing these design elements correctly enhances users’ sense of mastery over technology. Violating the standards makes the user interface feel brittle.”

“The biggest usability problems for checkboxes and radio buttons come from labels that are vague, misleading, or describe options that are impossible for average users to understand.”

The next article focuses on use of switches and checkboxes.

The name of this article is “When to Use a Switch or Checkbox.”

The article says that switches and checkboxes have similar functions, but different contexts.

“Switches and checkboxes are both used to activate settings.”

“Using these controls in the right context will make your user interface intuitive to use.”

• Switches are instantaneous actions
• When users turn a switch to “on”, they expect an instantaneous action as soon as the label appears.
• Any delayed effect or need for further action makes you think something is wrong.
• Switches should never require users to press a button to apply their settings. This is because a switch is already a toggle button. When you require users to press a submit button, you confuse them because it’s not what they expect.

• You should only use switches on settings that need to take effect instantaneously.

Checkboxes Require a Button Press

“A checkbox does not apply a setting at an instant like a switch [does]. Requiring a button press allows users to review their settings before they commit.”

This is a visual example from the article:

“If the user will change a batch of settings often, checkboxes save more time. But if the user will change only a few settings often, switches work better.”

Deciding Between Switch or Checkbox

“When deciding between a switch or checkbox, focus on context, not function. Ask yourself whether a setting should take immediate effect or not. Ask yourself whether users need to check their settings before they apply them.”

And that is all, folks.

In summary, a checkbox is used when you want something/a setting changed, or someone needs to select several things, and also when you want the user to think about the context of the settings before making a decision, before submitting. This is especially true if it’s something important. You can also select several things with checkboxes.

With radio buttons you can only choose one answer/response. The users know this because that is the standard usage of radio buttons, and the standard design. Also, as one of the articles mentions, you should try to use radio buttons and checklists (and I suppose switches too) in a vertical form instead of in a list because it looks better, clearer, like separate items, visually.

A switch is used when the user wants the action to be made instantaneously, right away, instead of having to think about it and then submit. It’s like a light switch. Something rather interesting came from one of the readers of this article and a comment her wrote, regarding switches. He said how you also have to think about the mental model of the action of an instantaneous change. He said,

“A switch, as implied, has an of and off state. If turned ‘on’, it will remain on until turned off. Like a light switch in the real world and like settings such as WiFi or Push Notifications. On is on, until stated otherwise. If this is true for the interaction (always on) then great, if not…

Checkboxes offer a different state, in that a user is turning ‘on’ temporarily and it is not permanent. This is important for certain user behaviors/interactions such as agreeing to terms and conditions, but a submit action takes place. Next time the user returns this feature will not be ‘on’.”

This above concept is really interesting. It relates the idea of how psychological everything is, how we think and how we behave, and how even the smallest detail in UX design has to be thoroughly thought-out, since a user could make a terrible mistake, such as delete an important file or transfer some big amount of money somewhere without intending to, just because the button or the wording wasn’t clear. And that’s another thing the articles said. You have to be very careful about HOW you word call to action items, to avoid errors and huge mistakes in usability.