6 ms·

> Of course, designers may not like the way this looks and we want to create a great looking custom switch. The general UI rule is use a switch when toggling h

> Of course, designers may not like the way this looks and we want to create a great looking custom switch. The general UI rule is use a switch when toggling has an immediate impact (similar to pressing a light switch) vs a checkbox when there's a submission step before it has an impact (similar to ticking a paper form then mailing it). See: https://www.nngroup.com/articles/toggle-switch-guidelines/ https://www.nngroup.com/articles/toggle-switch-guidelines/. It made sense after learning this but I didn't find the difference that intuitive before. A lot of UIs get it wrong (e.g. switches in forms, checkboxes for settings that immediately change something) but it only bugs me now I know which one to use. It's not only for cosmetics though.

kristiandupont 3y ago
I personally had not heard this but it does sound intuitive to me. A checkbox is literally something you would check on a form (i.e. piece of paper) before handing it in. A switch on the other hand, it something that offers immediate feedback in the real world.
- pavlov 3y ago
  It’s a useful distinction but frustrating to apply in practice because we don’t have a similar convention for many other UI elements like input fields and date pickers. You can’t tell at a glance whether these will produce an effect immediately after entering a value, or whether there is a separate submission action. In terms of primitive types and common UI platforms, we have this immediate/deferred distinction for booleans and enums. Booleans are represented by checkboxes vs. switches as already discussed. And enums are represented by radio buttons (the traditional form element) vs. multi-part buttons (which Apple calls segmented controls).
- tgv 3y ago
  Idk. There are enough switches that don't have an immediately noticeable effect, e.g. when you have to open a panel to turn things on or off, or when you have to go to another room. It's always hard to come up with the perfect definition/metaphor, but perhaps it's more like an operation that has a lasting effect. But like designers shouldn't overdesign, we shouldn't overthink what's "correct" use. If it works and/or feels natural, it's ok. If it doesn't, it's time to consider alternatives, but you shouldn't implement them because some rule says so.
vertnerd 3y ago
I wish someone came up with a better UI than the toggle. Usually, I understand what it means, but I often find toggles where it isn't clear what the state of the toggle is. Right vs left, color vs no color, just isn't obvious to me. A visible check in a box is crystal clear.
- Timon3 3y ago
  A toggle works fine if it's not treated as boolean, due to the exact problem you mention. What fixes it for me is having the meaning spelled out on both sides of the toggle, e.g. like this: dark (o ) light
  - runnerup 3y ago
    Separately, some UI's make it very hard to tell which side is selected. It's a rare problem, but especially anxiety-inducing for me when it does appear.
    - dylan604 3y ago
      are you using anxiety with a bit of hyperbole here, or is it really making you anxious? I can see it being confusing and needing extra time to really look at it rather than being instantly obvious, but it's nothing to cause stress. It's just a setting/option. It's not going to cause significant issues if misinterpreted. You can just set it the other way, and do it again. Is this the same thing that separates those that like to mash all the buttons and twist all the knobs to see what happens vs those that don't want to touch anything because they don't know what will happen?
      - runnerup 3y ago
        > are you using anxiety with a bit of hyperbole here, or is it really making you anxious? Depends on the setting. Sometimes they're for things that have greater than usual effects, like getting locked into a subscription payment or agreeing to additional charges for Spirit Airline flights. Other times they're for things that I have difficulty taking the initiative to address, like notification/unsubscribe settings, for which my ADHD only allows me occasional "windows" of time where I'm able to initiate or follow-through on changing the settings. Sometimes it doesn't really matter and I just scoff at the bad UI and it's not a problem.
Waterluvian 3y ago
I can absolutely see this. But to share a different perspective since “instantly vs. submit” doesn’t make sense in some of my software that’s constantly applying input changes on change: I use a switch to toggle one specific thing, checkboxes to pick zero, one, or many related things. Eg: switch: “slow mode is active for robots in this zone.” Checkboxes: “this applies to robot types A, C, D.”
- lelandfe 3y ago
  Apple can scarcely pretend to adhere to it, but their HIG on checkboxes, radios, and switches is good: https://developer.apple.com/design/human-interface-guidelines/toggles https://developer.apple.com/design/human-interface-guideline...
  - jwells89 3y ago
    Also worth noting that on macOS (where you’d see checkboxes), things like settings dialogs very rarely have “save” or “apply” buttons, with any settings changes taking effect immediately. Checkbox vs switch has no bearing on immediacy. The only exceptions are cases where partially applied settings can cause problems (like network settings) and the odd holdover that’s survived since the pre-OS-X days (like the settings dialog in Music, previously known as iTunes, previously known as SoundJam MP).
    - lelandfe 3y ago
      Great addition, thanks.
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]

kristiandupont 3y ago

I personally had not heard this but it does sound intuitive to me. A checkbox is literally something you would check on a form (i.e. piece of paper) before handing it in. A switch on the other hand, it something that offers immediate feedback in the real world.

pavlov 3y ago
It’s a useful distinction but frustrating to apply in practice because we don’t have a similar convention for many other UI elements like input fields and date pickers. You can’t tell at a glance whether these will produce an effect immediately after entering a value, or whether there is a separate submission action. In terms of primitive types and common UI platforms, we have this immediate/deferred distinction for booleans and enums. Booleans are represented by checkboxes vs. switches as already discussed. And enums are represented by radio buttons (the traditional form element) vs. multi-part buttons (which Apple calls segmented controls).
tgv 3y ago
Idk. There are enough switches that don't have an immediately noticeable effect, e.g. when you have to open a panel to turn things on or off, or when you have to go to another room. It's always hard to come up with the perfect definition/metaphor, but perhaps it's more like an operation that has a lasting effect. But like designers shouldn't overdesign, we shouldn't overthink what's "correct" use. If it works and/or feels natural, it's ok. If it doesn't, it's time to consider alternatives, but you shouldn't implement them because some rule says so.

vertnerd 3y ago

I wish someone came up with a better UI than the toggle. Usually, I understand what it means, but I often find toggles where it isn't clear what the state of the toggle is. Right vs left, color vs no color, just isn't obvious to me. A visible check in a box is crystal clear.

Timon3 3y ago
A toggle works fine if it's not treated as boolean, due to the exact problem you mention. What fixes it for me is having the meaning spelled out on both sides of the toggle, e.g. like this: dark (o ) light
- runnerup 3y ago
  Separately, some UI's make it very hard to tell which side is selected. It's a rare problem, but especially anxiety-inducing for me when it does appear.
  - dylan604 3y ago
    are you using anxiety with a bit of hyperbole here, or is it really making you anxious? I can see it being confusing and needing extra time to really look at it rather than being instantly obvious, but it's nothing to cause stress. It's just a setting/option. It's not going to cause significant issues if misinterpreted. You can just set it the other way, and do it again. Is this the same thing that separates those that like to mash all the buttons and twist all the knobs to see what happens vs those that don't want to touch anything because they don't know what will happen?
    - runnerup 3y ago
      > are you using anxiety with a bit of hyperbole here, or is it really making you anxious? Depends on the setting. Sometimes they're for things that have greater than usual effects, like getting locked into a subscription payment or agreeing to additional charges for Spirit Airline flights. Other times they're for things that I have difficulty taking the initiative to address, like notification/unsubscribe settings, for which my ADHD only allows me occasional "windows" of time where I'm able to initiate or follow-through on changing the settings. Sometimes it doesn't really matter and I just scoff at the bad UI and it's not a problem.

Waterluvian 3y ago

I can absolutely see this. But to share a different perspective since “instantly vs. submit” doesn’t make sense in some of my software that’s constantly applying input changes on change: I use a switch to toggle one specific thing, checkboxes to pick zero, one, or many related things. Eg: switch: “slow mode is active for robots in this zone.” Checkboxes: “this applies to robot types A, C, D.”

lelandfe 3y ago
Apple can scarcely pretend to adhere to it, but their HIG on checkboxes, radios, and switches is good: https://developer.apple.com/design/human-interface-guidelines/toggles https://developer.apple.com/design/human-interface-guideline...
- jwells89 3y ago
  Also worth noting that on macOS (where you’d see checkboxes), things like settings dialogs very rarely have “save” or “apply” buttons, with any settings changes taking effect immediately. Checkbox vs switch has no bearing on immediacy. The only exceptions are cases where partially applied settings can cause problems (like network settings) and the odd holdover that’s survived since the pre-OS-X days (like the settings dialog in Music, previously known as iTunes, previously known as SoundJam MP).
  - lelandfe 3y ago
    Great addition, thanks.

deleted 3y ago

[deleted]

deleted 3y ago
[deleted]