11
When to Use a Switch or Checkbox (uxmovement.com)
7 years ago from anthony thomas, ux designer
12 comments
Marc Edwards, 7 years ago (edited 7 years ago )
I wonder why the most important aspect of the decision was missed: Switches typically have a larger hit zone, making them more appropriate for multitouch interactions (the main reason switches were popularised was the launch of the iPhone and iPhone OS 1).
The article should probably be: “Multitouch? Use a switch. Mouse or trackpad input? A check box is probably best.”
A checkbox does not apply a setting at an instant like a switch. Instead, it’s accompanied by a submit button and takes effect after the user presses it.
What a web-centric view of the world. I can’t think of a check box in macOS that also requires a button press to activate it.
With switches, users have to wait for the system to apply a setting one by one.
The what now?
Roy Abbink, 7 years ago (edited 7 years ago )
Spot on Marc!
anthony thomas, 7 years ago (edited 7 years ago )
Author here. I get what you're saying. You're saying that switches have bigger hit targets so you should use them on mobile. Checkboxes have smaller hit targets so you should use them on desktop. So the principle here is bigger hit target = mobile, smaller hit target = desktop. The problem with this principle is that it's completely flawed.
If this principle were true, it would hold its weight under all circumstances but it doesn't. For example, your principle would postulate that an icon button with no text label should only be used on desktop because it has a smaller hit target. And a button with a text label should only be used on mobile because it has a bigger hit target. This is horrible advice because there are times when an icon button can save space on mobile and times when a text label can make an action clearer on desktop.
The problem with your principle is that you're only looking at the superficial cosmetic appearance of switches and ignoring the underlying mechanics of it. Design is not just how something looks, it's how it works. My principle laid out in the article focuses on what users expect when they interact with switches. Your principle only focuses on cosmetic appearance. This is why my principle is true and yours is flawed. And that's why the aspect you call 'most important' was purposely missed.
For example, your principle would postulate that an icon button with no text label should only be used on desktop because it has a smaller hit target. And a button with a text label should only be used on mobile because it has a bigger hit target.
No. That’s not a correct conclusion from my comment.
Mobile needs bigger hit targets. Roughly twice as large in each dimension.
Discussion about labels is a separate and orthogonal issue.
The problem with your principle is that you're only looking at the superficial cosmetic appearance of switches and ignoring the underlying mechanics of it.
“A checkbox does not apply a setting at an instant like a switch” is factually incorrect. They can both act instantly. As I said, you seem to be basing most of your article on web interactions. iOS, Android, macOS, Windows and other native platforms typically act instantly. The web can act instantly, if the developer wants.
The problem with your principle is that you're only looking at the superficial cosmetic appearance of switches and ignoring the underlying mechanics of it.
I wouldn’t call the interaction size superficial or cosmetic. The underlying mechanics of switches and check boxes are technically very similar — you hook up an action to a state. The action is defined any way the developer likes.
This is why my principle is true and yours is flawed.
The information you’ve presented is factually incorrect. Switches and check boxes can both act instantly or defer their action until some other event (form submition etc).
If you’re looking for an answer of when to use a switch vs a check box, each platform has a set of native controls:
- The web: Native checkbox widget, no switch widget.
- iOS: Native switch widget, no checkbox widget.
- Android: Native switch and checkbox widget.
- macOS: Native checkbox widget, no switch widget.
- Windows desktop: Native checkbox widget, no switch widget.
- Windows Phone: I think native switch and checkbox widget.
In most cases, the decision is made for you, unless you build a custom widget.
You've said nothing except I'm "factually incorrect" over and over. You've ducked all my points, provided no justification for why they're wrong and didn't even address the principle in the article which is the most important thing. You just kept harping on about yours which I've already proven is flawed. I mean, you don't even seem to understand principles because you can't even adhere to your own. You're not a guy I would trust to do UX or even speak on UX.
Unfortunately, this is an online forum. But if this were a real debate face-to-face, you would get debated into the ground because I would hold you accountable to every single point. You wouldn't be able to duck them like you are now.
Adrien Maston, 7 years ago (edited 7 years ago ) This is escalating quickly...
So the principle here is bigger hit target = mobile, smaller hit target = desktop
As I see it the principle is not that mobile needs a bigger hit target than desktop. The principle is that touch needs a bigger minimum hit target than mouse.
A 40 something pixels wide icon button on desktop does not necessarily need to be bigger on mobile. A 12px checkbox does.
Checkboxes and switches serve the same function : a boolean widget. Switches did became a thing with the first iPhone where it made sense to have a bigger hit target. They could have make a giant checkbox, probably tried and decided it was ridiculous and ugly. They could have make a regular checkbox within a larger hit target but not only did it make sense to have a bigger hit target, it also made sense to look like it. As a bonus switches were way cooler (remember how slide to unlock blew everybody’s mind). I feel like switches sort of became a mobile trademark.
A button does not have these issues thanks to its very flexible shape that both makes and shows the hit target. The button might benefit from a label so that you know what it does, desktop or mobile, but that is an other story.
The problem with your principle is that you're only looking at the superficial cosmetic appearance of switches and ignoring the underlying mechanics of it.
Usability and affordance are hardly superficial cosmetic issues.
You are stating your point as an actual fact and refusing every other reason to choose between a checkbox and a switch. Your point is not an actual fact. Checkboxes and switches make what we make them do, instant or not, desktop or mobile, web or native.
And then in the app landscape in 2016 :
Desktop native apps, where you use a mouse, are filled with « instant » checkboxes. Mobile native apps, where you use your fingers, are filled with « instant » switches (and « instant » checkboxes on android and windows).
Switches are native widgets of native apps on touch-enabled platforms. Not on traditional mouse controlled desktop, not on the web.
As a user, I do expect both checkboxes and switches to act instantly in native apps and to need a form validation on the web. Not as a rule of thumb but because that's the way I've been accustomed to in most cases.
It does seems like it comes down to mouse vs touch and/or native vs web. These are the facts.
What I think : Do not present your opinion has an actual technical fact and you should do just fine.
Checkboxes and switches serve the same function : a boolean widget. Switches did became a thing with the first iPhone where it made sense to have a bigger hit target. They could have make a giant checkbox, probably tried and decided it was ridiculous and ugly.
I wish we could know for sure. It seems very likely it went down exactly as you discribed, but it’d be great to hear some stories from the designers working on the team at the time.
As a user, I do expect both checkboxes and switches to act instantly in native apps and to need a form validation on the web. Not as a rule of thumb but because that's the way I've been accustomed to in most cases.
I agree. Unless there’s good reason not to, both should act instantly. Your point about instant form validation is a good one, too.
You've said nothing except I'm "factually incorrect" over and over.
Your central argument is:
Switches and checkboxes are both used to activate settings. But the immediacy of when users expect those settings to activate are different.
It is repeated many times throughout your article:
You should only use switches on settings that need to take effect instantaneously. If a setting requires a button press before it can take effect, you should use a checkbox instead.
It is incorrect.
Both check boxes and switches can act instantly. In fact, they typically do, everywhere except the web. Example: The “Enable this account” check box in Messages for Mac, turns the account on and off instantly.
All platforms have native controls. If you’re building an iOS app, there is only native switches. If you’re building a Mac app, there is only native check boxes. If you’re building a web page or web app, there is only native check boxes. The web has no native switches.
If you’re rolling your own custom UI widgets, you can make them behave however you like. They can be instantatious, or deferred.
It really can not be clearer than that.
Ariel Verber, 7 years ago
tl;dr: use a switch for changes to be made instantly, checkbox for changes to be made only after pressing a save button. badly designed blog trying to promote products.
Dirk HCM van Boxtel, 7 years ago (edited 7 years ago )
I feel like this is discussing the difference between "1/0" and "true/false".
- Both toggle between two values
- Both need a label for context
- Both could be big or small areas (felt like I had to add this due to previous discussions)
To me, the only difference is that one moves horizontally, whereas the other changes its look to indicate the state change.
Anything else is subjective I guess. You could say that one looks like it *toggles between two states, whereas the other looks like it either **includes or doesn't include something. But even that can be changed by the label.*
But again, these last few paragraphs are pretty subjective and circumstantial.
Both could be big or small areas (felt like I had to add this due to previous discussions)
Definitely. We do have the native controls on the platforms to use for comparisons though.
From a practical point, you're 100% right. Poor implementation can mess up even the best of intentions!
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now