Multiple options vs single option UI Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Why is it impossible to deselect HTML “radio” inputs?creating a switch for two optionsDeviating from the check-mark conventionChoice with a Radio button groupDo users understand this hybrid checkbox/radio control?Checkboxes or Radio buttons: Only one or zero choicesDisplay hierarchy of mutually exclusive optionsHow to design a form with lots of possible valuesDo non-technical users understand radio vs checkbox?Checkboxes, Radio Buttons, and Mobile Development
Co-worker works way more than he should
Error: Syntax error. Missing ')' for CASE Statement
Does the set of sets which are elements of every set exist?
401(k) cost basis
What's the difference between using dependency injection with a container and using a service locator?
What is a 'Key' in computer science?
Do I need to protect SFP ports and optics from dust/contaminants? If so, how?
Seek and ye shall find
Is a 5 watt UHF/VHF handheld considered QRP?
Is Diceware more secure than a long passphrase?
'Var' does not name a type!
FullSimplify a trigonometric expression doesn't work as expected
Book with legacy programming code on a space ship that the main character hacks to escape
Why did Israel vote against lifting the American embargo on Cuba?
How to not starve gigantic beasts
Where did Arya get these scars?
Is this homebrew racial feat, Stonehide, balanced?
Are all CP/M-80 implementations binary compatible?
Align column where each cell has two decimals with siunitx
Additive group of local rings
Trumpet valves, lengths, and pitch
AI positioning circles within an arc at equal distances and heights
Has a Nobel Peace laureate ever been accused of war crimes?
As an international instructor, should I openly talk about my accent?
Multiple options vs single option UI
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?Why is it impossible to deselect HTML “radio” inputs?creating a switch for two optionsDeviating from the check-mark conventionChoice with a Radio button groupDo users understand this hybrid checkbox/radio control?Checkboxes or Radio buttons: Only one or zero choicesDisplay hierarchy of mutually exclusive optionsHow to design a form with lots of possible valuesDo non-technical users understand radio vs checkbox?Checkboxes, Radio Buttons, and Mobile Development
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
On the dashboard we are building we got 2 sets of options users can pick:
Multiple options (checkboxes)
and single options (radio buttons behavior)
while the look of the components is similar, their uses are different.
In usability tests, users used these components without any difficulties or once they used and understand the functionalities they didn't have any issues to use them in the other parts of the product.
But, my designer colleagues argued that the components should look different and users have to understand if its a checkbox or a radio box from the first glance.
My aim was to keep the consistency and lower the cognitive load.
Any thoughts or inputs?
usability gui-design interaction-design checkboxes radio-buttons
add a comment |
On the dashboard we are building we got 2 sets of options users can pick:
Multiple options (checkboxes)
and single options (radio buttons behavior)
while the look of the components is similar, their uses are different.
In usability tests, users used these components without any difficulties or once they used and understand the functionalities they didn't have any issues to use them in the other parts of the product.
But, my designer colleagues argued that the components should look different and users have to understand if its a checkbox or a radio box from the first glance.
My aim was to keep the consistency and lower the cognitive load.
Any thoughts or inputs?
usability gui-design interaction-design checkboxes radio-buttons
If you go with this approach, it becomes crucial to make sure it's clear when only one option is allowed vs. multiple. For instance, your example has two selections made for the field "Age", which I wouldn't have expected to be possible. One way to make this clear without changing your elements is adding some help text like "Choose all that apply"
– nvioli
1 hour ago
Those gray options look more like they're disabled, rather than deselected.
– 200_success
1 hour ago
add a comment |
On the dashboard we are building we got 2 sets of options users can pick:
Multiple options (checkboxes)
and single options (radio buttons behavior)
while the look of the components is similar, their uses are different.
In usability tests, users used these components without any difficulties or once they used and understand the functionalities they didn't have any issues to use them in the other parts of the product.
But, my designer colleagues argued that the components should look different and users have to understand if its a checkbox or a radio box from the first glance.
My aim was to keep the consistency and lower the cognitive load.
Any thoughts or inputs?
usability gui-design interaction-design checkboxes radio-buttons
On the dashboard we are building we got 2 sets of options users can pick:
Multiple options (checkboxes)
and single options (radio buttons behavior)
while the look of the components is similar, their uses are different.
In usability tests, users used these components without any difficulties or once they used and understand the functionalities they didn't have any issues to use them in the other parts of the product.
But, my designer colleagues argued that the components should look different and users have to understand if its a checkbox or a radio box from the first glance.
My aim was to keep the consistency and lower the cognitive load.
Any thoughts or inputs?
usability gui-design interaction-design checkboxes radio-buttons
usability gui-design interaction-design checkboxes radio-buttons
asked 11 hours ago
Deniz ErdalDeniz Erdal
1,0972816
1,0972816
If you go with this approach, it becomes crucial to make sure it's clear when only one option is allowed vs. multiple. For instance, your example has two selections made for the field "Age", which I wouldn't have expected to be possible. One way to make this clear without changing your elements is adding some help text like "Choose all that apply"
– nvioli
1 hour ago
Those gray options look more like they're disabled, rather than deselected.
– 200_success
1 hour ago
add a comment |
If you go with this approach, it becomes crucial to make sure it's clear when only one option is allowed vs. multiple. For instance, your example has two selections made for the field "Age", which I wouldn't have expected to be possible. One way to make this clear without changing your elements is adding some help text like "Choose all that apply"
– nvioli
1 hour ago
Those gray options look more like they're disabled, rather than deselected.
– 200_success
1 hour ago
If you go with this approach, it becomes crucial to make sure it's clear when only one option is allowed vs. multiple. For instance, your example has two selections made for the field "Age", which I wouldn't have expected to be possible. One way to make this clear without changing your elements is adding some help text like "Choose all that apply"
– nvioli
1 hour ago
If you go with this approach, it becomes crucial to make sure it's clear when only one option is allowed vs. multiple. For instance, your example has two selections made for the field "Age", which I wouldn't have expected to be possible. One way to make this clear without changing your elements is adding some help text like "Choose all that apply"
– nvioli
1 hour ago
Those gray options look more like they're disabled, rather than deselected.
– 200_success
1 hour ago
Those gray options look more like they're disabled, rather than deselected.
– 200_success
1 hour ago
add a comment |
3 Answers
3
active
oldest
votes
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 mental model (user's view of how the system should work) we understand that a piece of text can be bold, underlined and cursive simultaneously so we expect that respective toggles should act like checkboxes. And we understand that text can't be right and left aligned simultaneously so it's not a surprise for us that alignment controls act like radio buttons. We know that and we don't need extra reminders about that.
You wrote that in usability tests, users used these components without any difficulties. I think that means that the behaviour of the components matches the user's mental model i.e. users understand and expect that they can choose several age-ranges and only one view (lists or thumbnails).
I took the example of Word's toggles from A. Cooper's "About Face 3. The Essentials of Interaction Design". He wrote about it as an example of a more graphical and more space efficient approach to the checkbox or radio buttons (see Chapter 21: Controls, Check boxes (p. 443) and Radio buttons (p. 446)). And also Cooper didn't say anything like these two types of toggles must look differently.
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
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.
Google docs and Microsoft Word are great examples of Sovereign Posture Applications: Users spend long periods of time manipulating documents.
The target users are usually intermediates. They will encounter these controls repeatedly over long use.
Certain controls that appear the same but behave differently don't pose too much difficulty after repeated prolonged exposure.
Most of us have become accustomed to the toolbar, as pointed out by another post:

Another example is OmniFocus, the task management application.
The inspector panel has details for repeated and scheduled events. It has a multiselect toggle showing which days of the week to include an event. It has the same effect as checkboxes:

The mental model for events is clearer to begin with, which probably helps in using these controls:
Events have:
- Start dates
- End dates
- Frequencies
- Repetition
For example, it's clear to me that I can go to Karate class Monday, Wednesday, and Friday. So I can select multiple days as I need to.
One time forms, rarely accessed 'Settings' pages, and seldom encountered UI can be challenging without clear labels and/or controls.
I'm not clear on your larger context, but clear labeling is crucial for users encountering your form for the first time, or infrequently:

It seems like you're in a good place, as it has been confirmed by user testing. Keep in mind that in some contexts, you'll design for perpetual 'first timers' that are venturing into unfamiliar territory.
add a comment |
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.
2
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "102"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f125231%2fmultiple-options-vs-single-option-ui%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 mental model (user's view of how the system should work) we understand that a piece of text can be bold, underlined and cursive simultaneously so we expect that respective toggles should act like checkboxes. And we understand that text can't be right and left aligned simultaneously so it's not a surprise for us that alignment controls act like radio buttons. We know that and we don't need extra reminders about that.
You wrote that in usability tests, users used these components without any difficulties. I think that means that the behaviour of the components matches the user's mental model i.e. users understand and expect that they can choose several age-ranges and only one view (lists or thumbnails).
I took the example of Word's toggles from A. Cooper's "About Face 3. The Essentials of Interaction Design". He wrote about it as an example of a more graphical and more space efficient approach to the checkbox or radio buttons (see Chapter 21: Controls, Check boxes (p. 443) and Radio buttons (p. 446)). And also Cooper didn't say anything like these two types of toggles must look differently.
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
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 mental model (user's view of how the system should work) we understand that a piece of text can be bold, underlined and cursive simultaneously so we expect that respective toggles should act like checkboxes. And we understand that text can't be right and left aligned simultaneously so it's not a surprise for us that alignment controls act like radio buttons. We know that and we don't need extra reminders about that.
You wrote that in usability tests, users used these components without any difficulties. I think that means that the behaviour of the components matches the user's mental model i.e. users understand and expect that they can choose several age-ranges and only one view (lists or thumbnails).
I took the example of Word's toggles from A. Cooper's "About Face 3. The Essentials of Interaction Design". He wrote about it as an example of a more graphical and more space efficient approach to the checkbox or radio buttons (see Chapter 21: Controls, Check boxes (p. 443) and Radio buttons (p. 446)). And also Cooper didn't say anything like these two types of toggles must look differently.
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
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 mental model (user's view of how the system should work) we understand that a piece of text can be bold, underlined and cursive simultaneously so we expect that respective toggles should act like checkboxes. And we understand that text can't be right and left aligned simultaneously so it's not a surprise for us that alignment controls act like radio buttons. We know that and we don't need extra reminders about that.
You wrote that in usability tests, users used these components without any difficulties. I think that means that the behaviour of the components matches the user's mental model i.e. users understand and expect that they can choose several age-ranges and only one view (lists or thumbnails).
I took the example of Word's toggles from A. Cooper's "About Face 3. The Essentials of Interaction Design". He wrote about it as an example of a more graphical and more space efficient approach to the checkbox or radio buttons (see Chapter 21: Controls, Check boxes (p. 443) and Radio buttons (p. 446)). And also Cooper didn't say anything like these two types of toggles must look differently.
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 mental model (user's view of how the system should work) we understand that a piece of text can be bold, underlined and cursive simultaneously so we expect that respective toggles should act like checkboxes. And we understand that text can't be right and left aligned simultaneously so it's not a surprise for us that alignment controls act like radio buttons. We know that and we don't need extra reminders about that.
You wrote that in usability tests, users used these components without any difficulties. I think that means that the behaviour of the components matches the user's mental model i.e. users understand and expect that they can choose several age-ranges and only one view (lists or thumbnails).
I took the example of Word's toggles from A. Cooper's "About Face 3. The Essentials of Interaction Design". He wrote about it as an example of a more graphical and more space efficient approach to the checkbox or radio buttons (see Chapter 21: Controls, Check boxes (p. 443) and Radio buttons (p. 446)). And also Cooper didn't say anything like these two types of toggles must look differently.
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 5 hours ago
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 6 hours ago
LanaLana
1614
1614
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Lana is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
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.
Google docs and Microsoft Word are great examples of Sovereign Posture Applications: Users spend long periods of time manipulating documents.
The target users are usually intermediates. They will encounter these controls repeatedly over long use.
Certain controls that appear the same but behave differently don't pose too much difficulty after repeated prolonged exposure.
Most of us have become accustomed to the toolbar, as pointed out by another post:

Another example is OmniFocus, the task management application.
The inspector panel has details for repeated and scheduled events. It has a multiselect toggle showing which days of the week to include an event. It has the same effect as checkboxes:

The mental model for events is clearer to begin with, which probably helps in using these controls:
Events have:
- Start dates
- End dates
- Frequencies
- Repetition
For example, it's clear to me that I can go to Karate class Monday, Wednesday, and Friday. So I can select multiple days as I need to.
One time forms, rarely accessed 'Settings' pages, and seldom encountered UI can be challenging without clear labels and/or controls.
I'm not clear on your larger context, but clear labeling is crucial for users encountering your form for the first time, or infrequently:

It seems like you're in a good place, as it has been confirmed by user testing. Keep in mind that in some contexts, you'll design for perpetual 'first timers' that are venturing into unfamiliar territory.
add a comment |
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.
Google docs and Microsoft Word are great examples of Sovereign Posture Applications: Users spend long periods of time manipulating documents.
The target users are usually intermediates. They will encounter these controls repeatedly over long use.
Certain controls that appear the same but behave differently don't pose too much difficulty after repeated prolonged exposure.
Most of us have become accustomed to the toolbar, as pointed out by another post:

Another example is OmniFocus, the task management application.
The inspector panel has details for repeated and scheduled events. It has a multiselect toggle showing which days of the week to include an event. It has the same effect as checkboxes:

The mental model for events is clearer to begin with, which probably helps in using these controls:
Events have:
- Start dates
- End dates
- Frequencies
- Repetition
For example, it's clear to me that I can go to Karate class Monday, Wednesday, and Friday. So I can select multiple days as I need to.
One time forms, rarely accessed 'Settings' pages, and seldom encountered UI can be challenging without clear labels and/or controls.
I'm not clear on your larger context, but clear labeling is crucial for users encountering your form for the first time, or infrequently:

It seems like you're in a good place, as it has been confirmed by user testing. Keep in mind that in some contexts, you'll design for perpetual 'first timers' that are venturing into unfamiliar territory.
add a comment |
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.
Google docs and Microsoft Word are great examples of Sovereign Posture Applications: Users spend long periods of time manipulating documents.
The target users are usually intermediates. They will encounter these controls repeatedly over long use.
Certain controls that appear the same but behave differently don't pose too much difficulty after repeated prolonged exposure.
Most of us have become accustomed to the toolbar, as pointed out by another post:

Another example is OmniFocus, the task management application.
The inspector panel has details for repeated and scheduled events. It has a multiselect toggle showing which days of the week to include an event. It has the same effect as checkboxes:

The mental model for events is clearer to begin with, which probably helps in using these controls:
Events have:
- Start dates
- End dates
- Frequencies
- Repetition
For example, it's clear to me that I can go to Karate class Monday, Wednesday, and Friday. So I can select multiple days as I need to.
One time forms, rarely accessed 'Settings' pages, and seldom encountered UI can be challenging without clear labels and/or controls.
I'm not clear on your larger context, but clear labeling is crucial for users encountering your form for the first time, or infrequently:

It seems like you're in a good place, as it has been confirmed by user testing. Keep in mind that in some contexts, you'll design for perpetual 'first timers' that are venturing into unfamiliar territory.
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.
Google docs and Microsoft Word are great examples of Sovereign Posture Applications: Users spend long periods of time manipulating documents.
The target users are usually intermediates. They will encounter these controls repeatedly over long use.
Certain controls that appear the same but behave differently don't pose too much difficulty after repeated prolonged exposure.
Most of us have become accustomed to the toolbar, as pointed out by another post:

Another example is OmniFocus, the task management application.
The inspector panel has details for repeated and scheduled events. It has a multiselect toggle showing which days of the week to include an event. It has the same effect as checkboxes:

The mental model for events is clearer to begin with, which probably helps in using these controls:
Events have:
- Start dates
- End dates
- Frequencies
- Repetition
For example, it's clear to me that I can go to Karate class Monday, Wednesday, and Friday. So I can select multiple days as I need to.
One time forms, rarely accessed 'Settings' pages, and seldom encountered UI can be challenging without clear labels and/or controls.
I'm not clear on your larger context, but clear labeling is crucial for users encountering your form for the first time, or infrequently:

It seems like you're in a good place, as it has been confirmed by user testing. Keep in mind that in some contexts, you'll design for perpetual 'first timers' that are venturing into unfamiliar territory.
edited 1 hour ago
answered 5 hours ago
Mike MMike M
12.6k12736
12.6k12736
add a comment |
add a comment |
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.
2
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
add a comment |
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.
2
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
add a comment |
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.
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.
answered 7 hours ago
AsqanAsqan
24125
24125
2
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
add a comment |
2
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
2
2
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
In my opinion this is less visually appealing and doesn't add much value
– GrumpyCrouton
3 hours ago
add a comment |
Thanks for contributing an answer to User Experience Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fux.stackexchange.com%2fquestions%2f125231%2fmultiple-options-vs-single-option-ui%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If you go with this approach, it becomes crucial to make sure it's clear when only one option is allowed vs. multiple. For instance, your example has two selections made for the field "Age", which I wouldn't have expected to be possible. One way to make this clear without changing your elements is adding some help text like "Choose all that apply"
– nvioli
1 hour ago
Those gray options look more like they're disabled, rather than deselected.
– 200_success
1 hour ago