Hacker News Reader

Comment by matteason | Hacker News Reader

This part of the article matches my understanding of the difference:

> Switch versus checkbox

> Generally, we recommend using a switch when the end user understands the user interface element as a setting that is either “on” or “off”. A checkbox is well suited for when the end user would understand the element as something to be selected.

View on HN

There’s a little more to it than that too. A switch is typically setting something that takes effect immediately, whereas a checkbox is a state setting that needs to be saved to take effect.

Isn't that mostly just a coincidental outcome of smartphone apps preferring the fancy switches while also having "auto-saving" options while less dynamic web forms were stuck with checkboxes as standard elements?

I've definitely seen checkboxes that took effect immediately as well, though rare.

It's a useful distinction to have though, as a user I expect a toggle to take effect immediately, but with a checkbox I don't, it is usually used for a "dirty" state that has to be confirmed by a submit action

There are situations were either behaviour is preferable to the other

That rule means you can't have any other controls on screen, because it's not true for them and you can get into a semi-saved state. I believe it was just a niche designer factoid which sort of made it to reality by posts claiming that it's true. But it's way below the user uncertainty threshold to become a useful rule.

I'm not against immediate effects on switches (or any other controls), but they must clearly signal the immediate action. E.g. I've seen some UIs presenting a short spinner on its button and delaying the colors and/or the shift.

I’ve heard this said before, but I’m too skeptical to add it to my mental Rolodex of “common sense UX.” I see far more sites not doing that with switches, so I’m unsure the general population has that behavior internalized.

Reply on news.ycombinator.com