Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Apple used sliding checkboxes. Then everyone copied Apple. It's an annoying industry trend but in terms of clarity I don't think it matters at all in this case. For a while people also used push buttons with "lights" indicating on/off but those have been phased out almost entirely now.

I don't think there's much of a difference between a checkbox and a toggle if you size them right. Toggles are easier to size up to touch screen size so on touch screens they make sense. On desktop, in non-touch mode, the oversized control kind of irks me, though.

"On" versus "off" is always clear, but the question "did I set it correctly" depends on the phrasing of the checkbox labels. What does "FizzBuzz enabled when widgeting" being on or checked mean?

Design wise, I think generally the toggles are reserved for cases when you turn on a feature or service, and checkboxes just modify that feature's/service's behaviour. "VPN" is a toggle, but "auto-connect VPN" is a checkbox. "Accessibility" is a toggle, but "always overlay mouse cursor" is a checkbox.

On touch screens the bigger toggle buttons make more sense so I think on Android/iOS you'll always see them in the place of a checkbox.



> toggles are reserved for cases when you turn on a feature or service, and checkboxes just modify

Oh wow. I've never thought about this before but that is very intuitive.

Toggles have a physical, analog equivalent, like a switch or lever. Checkboxes don't really map to meatspace; they're strictly a logical construct.

Makes sense that toggles do big changes and checkboxes tweak.


Checkboxes map into meatspace, they copy checkboxes/tickboxes in paper forms. The things they make you tick to confirm that they can phone you, or the thing you fill out when voting on a paper ballot or in a multiple choice test.

Admittedly not as physical as buttons, but they were designed as a copy of an existing thing.


That analogy seems to support the idea that checkboxes require a "save" button to apply the change. In real life, merely ticking a box on a piece of paper doesn't do anything; you have to give the piece of paper to someone.

On the other hand, a toggle switch (like a light switch) has an immediate effect.


Yes that's why you often see checkboxes in place when agreeing to terms and conditions, whether it's on mobile or on desktop.


I agree that toggles make much more sense on touch-screens (which is why Apple used them).

Apple ones also light up green (or dark background) when "on" and grey (or light background) when "off" - which seems pretty clear to me.


Apple ones can also show 0 or 1 labels if you turn the option on in Accessibility. :)


iOS used to only have light/dark. How the heck am I supposed to know which one is on? I believe you when you say that dark is on, but for the physical toggle I use most (i.e. a light switch) dark is off.

Green is fine now, because I'm fortunately not red-green colourblind.


The world fell apart when flat minimilasm removed all the indicators that the "on" side was 'on', leaving the grand mistery "does "on" mean "it is on", or "push this button to turn it on"?


As others have pointed out, that ambiguity comes from putting a verb in the text next to the toggle. "Disable Feature" next to a switch in the ON state is weird because it indicates the feature is disabled when the switch is on. Putting "Feature" as the text and the toggle as the only indicator of on/off enabled/disabled clears it up.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: