Does a list of checkboxes necessarily mean multiple choices?

Question

I'm currently reviewing the usability of an e-commerce website. When the user searches a product, filter options are provided to refine his search.

The following list of checkboxes is available:

^{download bmml source – Wireframes created with Balsamiq Mockups}

The user can't select multiple choices which is pretty unusual for me. For instance, the user can't view all the products less expensive than $1000 at the same time.

I'm wondering if there is a convention which states that checkboxes necessarily mean 'zero or more choices', and radio-buttons mean 'one single choice'.

Answer 1

In the original GUI guidelines from the Lisa/Macintosh, Xerox Star, and Microsoft Windows, check boxes are, as the name implies, something you can mark (with a check-mark) if you wish to select or mark it - or clear if you wish to deselect it. Each checkbox choice is independent of each other, in terms of their activation.

Radio buttons, on the other hand, got their name from the buttons on your car radio or home radio/tuner. Just like you can only select one radio station to listen to at a time, you can only select one option from a list of radio buttons.

So, to answer your question - yes, according to all widely accepted guidelines and conventions, from their inception, checkboxes "mean 'zero or more choices' and radio-buttons mean 'one single choice'."

It is interesting that these have become so ingrained in user interfaces over the last 25+ years that the origins have been forgotten.

I don't think the original UI widget guidelines are available online, but you can find the current rendition for Windows check boxes here:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb246460(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb226806(v=vs.85).aspx

and for radio buttons (which they've renamed to "option buttons") here:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb246443(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb246423(v=vs.85).aspx

and here are the corresponding guidelines from Apple:

https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html

Scroll down the page to find the sections about Radio Buttons and Checkboxes

For a discussion by Jakob Nielsen on the subject, see this article: http://www.nngroup.com/articles/checkboxes-vs-radio-buttons/

Here is his salient point - read his full article for amplification and examples:

When to Use What Widgets

Ever since the first edition of Inside Macintosh in 1984, the rule has been the same for when to use checkboxes versus radio buttons. All subsequent GUI standards and the official W3C Web standards have included the same definition of these two controls:

1. 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.

2. Checkboxes are used when there are lists of options and the user may select any number of choices, including zero, one, or several. In other words, 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 a single option that the user can turn on or off.

Answer 2

Yes, there is a convention:

checkboxes = option for multiple choices

radio-buttons = only one single choice among the options

Answer 3

The behavior of checkboxes learned by users is to be able to choose multiple options.

In your case, it may be a relic of some former functionality, e.g. a form with some strange dependencies.

Answer 4

Not only is this a convention, but the expected behavior is explicitly called out in the HTML 4.01 spec (and I wouldn't be surprised if it was in pretty much every other version, as well):

Several checkboxes in a form may share the same control name. Thus, for example, checkboxes allow users to select several values for the same property.

[...]

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 switched "off".

To reverse this is purposely avoiding the standard behavior, making the website more confusing for users, and actually making the development harder. I also don't see how you could make this work for users with JavaScript disabled.

Answer 5

Traditionally, checkboxes have been used to indicate simple on/off choices. Occasionally, they are used to indicate on/partially-on/off or on/off/indeterminate state (the technical term for that being tristate checkboxes), but that's unusual and I do believe a lot of users get tripped up by that. (For a specific example of the latter, try the folder properties dialog in Windows Explorer when some files have the read-only attribute set and some do not.) For example, the "read-only" and "archive" file attributes are not interrelated, and can be toggled independently of each other. Doing it with any mutually-exclusive control would require four controls instead of two: off/off, off/on, on/off, on/on. It gets even worse if you consider the "some of the selection are 'on' and some are 'off'" state: it balloons to nine (3^2) possibilities. Add a third and you have 27 (3^3) controls to keep track of! MS-DOS used four file attributes: archive, read-only, system and hidden. With "some on and some off", that adds up to 81 possible choices (even without, it's still 16 different combinations to keep track of).

Radio buttons, on the other hand, indicate that only a single choice can be made. They also usually indicate that a choice must be made, either by accepting some default value or by making an explicit choice.

On the web, even with few choices, comboboxes or selection lists of some kind that display only the currently selected choice (until the control is activated) seem to be common. I'm not sure what the actual usability aspects are, there, myself, but radio buttons can certainly be made less readable. For any non-trivial number of choices, there are certainly upsides to a combobox approach from a UI design point of view.

Personally, when I see radio buttons I know that only a single choice can be made. If I see checkboxes, I generally expect that more than one choice is possible -- and when the UI starts to actively work against the user's expectations, it causes frustration and acute forehead contact with wooden or other skin-covered surfaces.

As for references, I'm not sure how much it counts but even Wikipedia's introductory sentence on the subject says that "a checkbox (check box, tickbox, or tick box) is a graphical user interface element (widget) that permits the user to make multiple selections from a number of options (contrary to a radio button where only one choice is possible) or to have the user answer yes (checked) or no (not checked) on a simple yes/no question.".

Answer 6

Back to Leo's original question, I guess that he has inherited a non-designed UI where a not-quite-expert programmer lumped together a bunch of checkboxes without further analysis, nearly at 3:00am.
And that his goal was to provide the user a means to select price ranges in a smart way.
But that by allowing the users to check any button they got strange price-ranges, not a single segment but several, and that it was either difficult to program the query, or non-performant, so they tried to add restrictions in order to force a single price range.

The solution is to replace the checkboxes group by any other means to select a price range.
Like for example two radio button columns labeled like from and to, or a single one and fix the lower bound as 0$, or a range slider.