Hacker News Reader

Comment by seanwilson | Hacker News Reader

> 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/.

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.

View on HN

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.

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

I agree, but it seems like a lot of times you get:

    (o foo)
    (bar o)

And I don't know if I'm supposed to click it to change to `foo`, or if that means it is already in the `foo` mode.

That's definitely much worse, both due to what you describe, and due to the fact that you don't know what the label on the other side says.

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.

(o ) "Do you want to receive marketing emails from our partners?"

This is absolutely a dark pattern.

Even worse when there's not even a grammatical structure, like

"opt-out options"

"annoying marketing emails (o )"

am i... enabling the thing? opting out of the thing?

It's also a stupid pattern. Privacy and spam laws usually require informed consent. They might as well just not ask for anything, because any consent they get this way doesn't count for shit.

This can be used as a dark pattern. If you want a user to use a particular setting (e.g. “Customize my ad experience.”) you can just make it unclear which they’re choosing.

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?

The worst offender to me is the ambiguous ui around creating a teams meeting for meetings created through whatever we are calling the outlook web thing these days. You don’t find out if you did it right until you have sent an email to your attendees with an erroneous teams link. And yes that is anxiety provoking.

Of course part of what makes it ambiguous is that there is a setting somewhere completely different which when set will add a teams link whether the slider is set or not.

> 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.

(I'm gonna abuse your example to rant about dark mode selection interfaces.)

There's a small problem with your example: Dark mode isn't a binary setting.

For modern applications, there should be 3 settings: System, Light, and Dark. (I like to use a dropdown menu to select the theme).

This makes it work for people whose theme changes automatically between day and night (it's a built-in system setting on macOS, and possibly Windows). L

For a web app, Light and Dark can set a value in localStorage which sets the theme manually, but System should remove the setting.

You can detect the correct theme when the page is loaded, and also add an event listener to detect theme changes (so that either the user or the OS can change the current theme). It's actually not too difficult to set up properly.

I think the first widespread use of a toggle was in iOS a long time ago.

The core function of a toggle is to - well - toggle.

    Off (o  ) On

And the way it was used was

    Dark       (o  )

or Dark ( o)

Radio buttons would work better.

It depends on the structure of your site. If you have, say, 10 pairs of boolean options in quick succession, toggles work way better than radio buttons.

Switches seems like an innovation that just makes UI worse.

Checkboxes are easy to understand.

If there is immediate effect then using a checkbox also works perfectly fine.

The switch is just always worse (IMO).

> Switches seems like an innovation that just makes UI worse

I once visited a site that had a hamburger menu holding the navbar that auto-hid if you clicked away. They also had a switch on the corner of the opposite side of the screen that opened the navbar and kept it open

I still sometimes wonder what was going through the UI guy's head when they made that

Total aside: but related to ambiguous true/false designation: A lot of times when people write articles like "Ten Myths About NodeJS", it is unclear in each of the numbered items whether the stance initially described is the incorrect myth, or the correct view as proposed by the author. To make it worse, some writers vary the structure between items!

> A visible check in a box is crystal clear.

For the "off" state though, I've never found an empty square outline being that clear (this looks similar to a button or a text field) or easy to spot, and a cross/X in the square instead can also be confused with "on". Not saying a switch fixes this however.

The most annoying toggle is the Spotify no-repeat/repeat-all/repeat-one button. Is it currently not repeating? When it has the dot, is it repeating one song, or all of them, and will pressing it make it repeat just one?

Agreed. The Spotify UI is bad in general, but this one especially. I’ve been using it for years and I still have no idea what I’m doing there.

The article linked by the commenter above addressed your concern. They mention the toggle should have an _immediate_ state change. I really liked the iOS airplane mode example the article used:

> When turning airplane mode on for iOS, Apple provides immediate results by changing the cellular bars in the upper left-hand corner to an airplane icon.

To summarize, it sounds like the toggles you've experienced haven't led to an immediate state change, which likely identifies them as better candidates for a checkbox like you mentioned.

Yeah, too often. But that's not the toggle's fault. The majority of the time the design (colors) and the associated label are the root problem. A toggle doesn't have to be ambiguous. Unfortunately, designers / UX'ers seem to think so.

A big offender here is (was?) instagram’s privacy settings. I recall trying to help my mom turn her profile to be private and we were both confused: does the blue mean it is private or not?

Honestly, besides being standard, checkboxes solve all of your problems.

That separation between immediate and delayed effect seems quite artificial to me, and doesn't exist at all on other types of inputs. It looks like a bad, post-fact justification created just to placate some masses instead of for good fundamental reasons. (And yeah, I do know who I'm criticizing here.)

Anyway, it's a lost battle, so whatever, let's leave with the bad consequences.

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.

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).

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.

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.”

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-guideline...

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).

Great addition, thanks.

Reply on news.ycombinator.com