HN Explorer

Ask HN: Why are toggle switches replacing checkboxes? Isn't on/off less obvious?

445 points by RjQoLCOSwiIKfpm ↗ HN
Every website and software seems to move to the left/right sliding thingies.

I know the right side is on.

But whenever I have to use them, I always have this little doubt on my mind of "did I really set it correctly?"

Am I going crazy or are these things a fad with much worse usability than checkboxes?

377 comments

[ 1.1 ms ] story [ 396 ms ] thread
efortis
I'm not a fan of toggles, but they might be better because they usually have an extra text saying "On" or "Enabled" in addition to the label.

For example:

    The label  [  *] On
A checkbox with a good label [1] is fine, and it's better in the sense that it has a third state (for indeterminate).

[1] https://blog.uidrafter.com/guidelines-for-checkboxes

hedora
The completely ambiguous:

   Enable the label [O @]
Is becoming more popular.
lylejantzi3rd
Is it? Dark mode/light mode toggles are very new and are now everywhere. It's a single image of either a sun or a moon with no text whatsoever. Half the sites show the sun when light mode is on and half the sites show the moon when light mode is on. Is the toggle supposed to reflect the current state? Or is it supposed to tell you what's going to happen when it gets clicked?
kiawe_fire
To me, the paradigm only works if both sides are labeled in both states.

    Light [* ] Dark
This is essentially how a physical switch would be labeled, and is the best way to prevent ambiguity - the current state is the label that the switch is closest to.

But most implementations don’t do that. And I can understand why, because the following…

    Show Notifications   Yes [* ] No
…is a bit awkward looking.
citrin_ru
On/Off labels confuse me. I often click on ‘On’ when I want to enable something (this is how you do with a mechanical switch) only to discover that I likely disabled the thing. Old school checkbox is less confusing and doesn’t require additional words.
the_cramer
Three state checkboxes are available nearly everywhere, not sure what is better about that in toggles.
ComodoHacker
Isn't the need for extra text a sign of flawed design though?
JoeyBananas
A toggle switch is better because it has an animation.
toast0
You can animate a check too, if you like animation. Gotta make it a stylized check while you're at it, instead of just a filled in box or an x
jordanwallwork
Absolutely, just google 'css animated checkboxes' and you'll get a tonne of solutions
8bitsrule
Just wait ... before long it'll be a smiley face for On, a frown for Off. After that, 'On' is accompanied by pschedelic-colored wavefronts crossing the page.
xigoi
I sure hope you're checking for prefersReducedMotion.
birdymcbird
maybe follow up question is what problem being solved.

do users not intuit checkbox button? is this some problem being solved or more of fad?

netsharc
Probably because checkboxes in real life exist mostly on paper, but when the iPhone came out, the skeumorphic designers wanted to make it look like a sleek device. E.g. the sound recorder app had an image of a big retro-style microphone, and a checkbox would look out of place there.

Probably a button that stays depressed and "lights up" when touched would be more similar to a checkbox. Touch again to uncheck and it will go undepressed.

kazinator
You see them used because they are skeumorphic, and there is a general trend in user interfaces to go skeumorphic across successive generations.
fsckboy
radio buttons are skeuomorphic and much easier to understand how to operate and get the result you want. Slider toggles are pure fashion and skeuomorphic only in that they are as difficult to use as some recessed sliders are, but without a skeuomorphic fingernail to grab them.

There are physical things that are difficult to operate irl, and there's no reason to skeuomorph difficult things to use.

but even better, what's wrong with letting me choose what I want? You can have whatever UI you like, it doesn't need to affect me. That's the whole idea behind a personal computer, it's my slave, it's my servant, it does what I want, to make my life the way I want it. Software is the first human technology to offer this promise, it's only the weak of mind, ego and will who see it as a way to impose their stunted vision on other people.

kazinator
Slider toggles are skeumorphic in that there are such physical switches and they look like those switches. Those classic radio buttons which are circles with a black dot are skeumorphic in the same sense that checkboxes are: they are an imitation of elements seen on paper forms.

You don't have to "grab" slider controls; if you just click anywhere in their display area to toggle them.

E.g. try an example here: https://www.w3schools.com/howto/howto_css_switch.asp

The sliding is just an animation sequence which replaces the appearance/disappearance of the checkbox with alternative images. In the above example, you in fact cannot grab anything and slide it left to right. All you can do is click.

If you're confronted with some UI in which you have to actually pull a slider left or right and cannot just click on it, complain to the vendor.

kazinator
Your idea behind the personal computer unfortunately no longer exists outside of the world of FOSS.

A device with a proprietary OS is now not really yours. It's something that you depend on for access to essential services and which you got for a deeply discounted price in exchange for giving up control, personal information, privacy and access to your eyes and ears by advertisers.

parasti
I don't get it either. I never know which side is on and/or which background color means on, unless they're using green/red. You say "right side is on", but I never even realized this until now.
kioshix
I've encountered sliders that were colored red/gray, where the ON state was to the left and red was on. It was a cookie consent thing, and I was confused. I guess that was the purpose.
foreigner
Be careful, red/green colourblindness is the most common kind of colourblindness.
teamonkey
Also colour associations are cultural, not universal
jeroenhd
As are left and right positions of a button.

Really, the only thing I can think of that clearly indicates the state of these buttons is the ⏽ vs ⭘ distinction because those glyphs have been made specifically for this purpose.

kps
I know ⏽ means on, but if I see ⏽, does that mean it's currently on, or that it will be on if I move the toggle to the location of the ⏽?

   Off ( ▢) On
       (⏽▢)
       (⭘▢)
parasti
Are they? Seems to me color associations are conventional, not cultural.
scyzoryk_xyz
Checkboxes come from older mouse/cursor UI’s, toggles come from newer touchscreen UI’s.
mikeyla85
Checkboxes are just as usable as toggles on touchscreen. It doesn't have to do with the tech, it's just that toggles are newer.
scyzoryk_xyz
I wouldn’t dare make comments on what’s more or less usable in an HN thread since everyone here is such an expert on these things.

Toggles came along with iOS when the UI was skeumorphic ca. 2008. Don’t know whether it has to do with tech, but that’s when we first got those.

As far as actual evidence, I do UX testing of a touchscreen/cursor application and we have both scattered throughout. I haven’t ever seen anyone have any difficulty understanding, using or differentiating between either. In our results this simply isn’t a problem with investigating.

barneygale
> I haven’t ever seen anyone have any difficulty understanding, using or differentiating between either. In our results this simply isn’t a problem with investigating.

I'm not sure if this was meant as reassuring, but for me it only reinforces my view that UI/UX folks don't have a clue what they're doing.

boomboomsubban
Checkboxes can be just as usable but they're often smaller and often more tightly spaced, which can be a pain to navigate on a touchscreen.

I'm not saying that's a good reason, but it is a reason besides being newer.

kevin_thibedeau
Checkboxes are slightly problematic in touch UIs because they are generally scaled to a similar size as text and small enough that they are occluded by a fingertip. Sliders leak information about their state while you touch them.
flohofwoe
Then why has macOS Ventura toggles all over the place, even though it's pointer-driven? (it's actually a wild mix of toggles and checkboxes in the new Settings UI)

There seems to be some logic behind it though: Toggles are often used alone to switch things on/off (for instance Wifi or Bluetooth), while checkboxes are often used in groups for "less important things". But maybe I'm just imagining that there's an actual reason behind it ;)

mathieuh
From https://developer.apple.com/design/human-interface-guideline...

Switches

--------

Avoid using a switch to control a single detail or a minor setting. A switch has more visual weight than a checkbox, so it looks better when it controls more functionality than a checkbox typically does. For example, you might use a switch to let people turn on or off a group of settings, instead of just one setting.

In general, don't replace a checkbox with a switch. If you're already using a checkbox in your interface, it's probably best to keep using it.

Checkboxes

----------

A checkbox is a small square button that’s empty when the button is off, contains a checkmark when the button is on, and can contain a dash when the button’s state is mixed. Unless a checkbox appears in a checklist, a descriptive label follows the button.

Use a checkbox instead of a switch if you need to present a hierarchy of settings. The visual style of checkboxes helps them align well and communicate grouping. By using alignment — generally along the leading edge of the checkboxes — and indentation, you can show dependencies, such as when the state of a checkbox governs the state of subordinate checkboxes.

saagarjha
> In general, don't replace a checkbox with a switch.

Someone tell Apple's Settings team

leokennis
Someone fire Apple's UI/UX team, and bring back the people from the Leopard era who actually understood the value of an understated, predictable and standardized UI.
DonHopkins
It's been decades since Apple had competent compassionate trained UI designers instead of narcissistic showboating cosmeticians, who'd even heard of, let alone read or actually written, Apple's own Human Interface Guidelines from 1978 onward, and aren't just motivated and addled by cocaine and a burning desire to prove to the world they're actually sensitive artists joyfully expressing their deeply unique spiritual creativity to immortalize themselves in the historic pantheon next to Leonardo da Vinci, and not mere usability engineers navigating difficult tradeoffs and conventions and applying sound scientific principles so users can actually get work done, instead pointlessly changing and banishing practical pixels and affable affordances that were there for reasons they're blissfully unaware of, which they wouldn't give a shit about even if Bruce Tognazzini, Bill Atkinson, Don Norman, and the ghost of Jeff Raskin themselves begged them to, simply to polish their resumes and burnish their egos, by spraying their sweaty cloying musk over every possible surface merely to express their ownership, just like the Cat in Red Dwarf. [But I digress...]

Red Dwarf - The Cat - That be mine!

https://www.youtube.com/watch?v=Q54lVO7elt0

How Apple Is Giving Design A Bad Name (2015)

https://www.fastcompany.com/3053406/how-apple-is-giving-desi...

A history of Apple HIG table of contents – the philosophy and principles

https://modelessdesign.com/backdrop/401

Rediscovering Apple’s Human Interface Guidelines from 1987: UX Lessons from the Dawn of the Personal Computer

https://blog.prototypr.io/rediscovering-apples-human-interfa...

mpweiher
Because we have to phone-ify everything, whether it makes sense or not.

(Narrator: it never does)

iforgotpassword
Because everything just gets worse as you age. Sure, my dad said it too back then, but they just didn't get how the world moved on and improved. This time around though it's real, everything gets more stupid and dumb and I hate it.
WesolyKubeczek
I wonder when you understand your dad was right all along.
orlp
It's a two steps forward, one step backwards thing. The things you are noticing really are a step backwards, but that doesn't mean progress overall is going backwards.
sofixa
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.

Douglas Adams

Dalewyn
I'm early- to mid- 30s (<35), and I hate basically every UI shenanigan that was invented in the past 15 years or so.

Which is to say, Douglas Adams might need to adjust the time window in #2 a bit.

theandrewbailey
I'm a member of Generation Y, because that's what we were before all this weird sh*t happened.
ilyt
To be entirely fair invent -> improve -> cost cut often leads to worse UIs.

Like when car manufacturers decided that knobs are bad and on top of people hating it it was proved to cause more distractions to the drivers

https://www.vibilagare.se/english/physical-buttons-outperfor...

Part of that is trying to have "one size fits all", why waste time perfecting design for multiple cases where you can just shove touch screen oriented design to desktop OS and "just" waste some space ?

LAC-Tech
Or maybe some things get worse and some things get better and we should stop pretending that it's impossible for things to get worse in tech.

It reminds me of when I see old photos and everyone is dressed up so much more nicely than today. And people either respond with "akshually hoodies are just as nice as pin stripe suits" (come on, you know they're not) or "oh what you want to go back to leaded petrol and no personal computers and smoking everywhere and drink driving?" (no, just the clothes).

Nuance people, jeez. You can pick and choose things in the past that were better or weren't.

seanhunter
My pet peeve is the labeling of these things.

1)I'm going to give you an easy one to start. You see a toggle switch. It is set to on (probably - the little colour bar in the switch is coloured in).

It is labeled "Disable fnurbification".

Okay now what? Does "on" mean I'm going to be fnurbified? Does switching the switch disable the fnurbification so I actually have to switch it to "off"? No that's crazy. "on" means "disabled", cognative dissonance aside.

2) You see a toggle switch. It is set to on like before. It is labeled "Disable fnurbification".

We learned before that "on" meant "disabled", but that filled us with a vague sense of unease. For whatever reason we try toggling the switch. The text changes to just "Fnurbification"

Okay really now what? Is my fnurbification on? You try flicking the switch back. The colour fills in and the label changes to "Disable fnurbification" again. Okay what are we supposed to do?

What's happened is the designer has read a post on medium about accessibility and that screen readers don't read out the colour of the filled in part of a toggle switch, and has decided to help by changing the label when the state of the switch changes.

The problem is now the label could either be describing the current state or be describing what happens when you flip the switch. And there's really no way of knowing. I've seen this very often with the UX for boolean selectors where they use things like buttons rather than toggle switches. Does pressing the button do the thing it says on the label or does the label describe where we are now and pressing the button will reverse that? No way to be sure.

Postscript: Notice that whatever you decide is correct in the second case could change what you would do in the first case if the first type of selector is one that would change label when you toggle it.

topicseed
200%. I find them "cute" so tried to use them in some internal tools with React. And.... I confused myself on this very exact issue you describe so I changed to a regular checkbox.
jrs235
Isn't the 'easy' fix to have the label read "Fnurbification is on" and "Fnurbification is off"?

Clarification: the label should toggle when the GUI toggle switch is toggled.

seanhunter
For sure, there are ways to not have it ambiguous.

That said, people use this UX pattern all over the place, and sometimes I'm sure on purpose. Istr one iteration of facebook's data privacy and sharing dialogue used to have it. There was a switch called something like "Enable privacy protection" and you see it set to "off". So you switch it "on" and the label changes to "Disable privacy protection". So which one gives me the privacy protection?

bentcorner
IMO labels should never change state. If you need explanatory text about what state the user is in, stick it below the checkbox.

Privacy protection [ o-- ]

Privacy protection is disabled. Other users can blah blah blah

Privacy protection [ --o ]

Privacy protection is enabled. Other users cannot blah blah blah

Sohcahtoa82
I find it very hard to believe that the ambiguity isn't deliberate.

I imagine at least 90% of people, upon seeing an option to enable privacy protection, would enable it. But by making the option confusing, you'll end up with people that want it on and inadvertently turn it off.

It certainly wouldn't be Facebook's only dark pattern.

naet
It can be ambiguous as to whether the label describes the current state, or the future effect of pushing the toggle.
IshKebab
No, the label should always say what the toggle or checkbox does when it is enabled. If you want to make it extra extra clear (because so many apps have muddied the water by doing it wrong) you should probably put additional small text nearby that changes. Like this:

  [ ] Foo
  *Foo is disabled*

  [X] Foo
  *Foo is enabled*
Also you should not have double-negative check boxes ("disable foo").

I'm not a UI designer but I think this is pretty obvious to anyone that has used bad checkboxes (like OP). (I don't think the problem is unique to slide toggles; I've definitely seen similarly bad checkboxes.)

pbhjpbhj
>you should not have double-negative //

Hmm, I'd like it if that always made sense, but sometimes the default state, with nothing active, is for Foo to be on. So "Disable Foo" is doing something not normally required, or something most people don't want. Sometimes it does make sense that _not_ performing a reduction in Baz is default, and that default is off.

You could probably solve it by renaming a feature to used an antonym, but not everything has an antonym [that people know, or that makes sense].

gisborne
I’m puzzled why you equate “default state” with “nothing active”. If the default should be that thing the button says is on, then have the button default to being in the active state.

The language even for discussing this is tiring to read…

IshKebab
The better solution to "is this the default" is to just have some mechanism for indicating whether the value has been changed, and a way to reset it to its default.

This is quite common in UIs. It also has the benefit of working for all controls, not just checkboxes.

ilyt
> Hmm, I'd like it if that always made sense, but sometimes the default state, with nothing active, is for Foo to be on.

Then foo will be checked on by default. That's not a problem.

    [X] Send notifications
Is perfectly unambiguous.

What I'd like to see with every option like that is something showing whether it is in default state or not so user can easily glance what was changed from default. "reset to defaults" per page of settings is also appreciated.

amelius
Too verbose.

I personally prefer a balloon that says "x is on" that appears when you toggle the switch.

[deleted]
(comment deleted)
somat
There are two conflicting schools of thought that I suspect will never reconcile.

the people who think the button should show what state it is in.

and the people who think the button should show what state it will change to when activated.

stonecharioteer
Oh there is a special kind of hell reserved for the latter crowd.
amelius
Yes, a hell where all the switches show the current state.
Kaotique
Glad the latter does not design rockets, planes and cars.
xmcqdpt2
Not sure if you are being sarcastic, but they do design cars. Aren't tesla menus full of those kind of toggles?
bklw
Yes they are, but the labels don't change when the setting is toggled.

It says what it is, and the toggle says if it's on or off.

The toggle is just a visual, it can be tapped just like a checkbox.

jaitsu
"X is currently disabled" resolves it
tjansen
Not for me, labels like that confuse me even more. I rather have just "X" with a checkbox next to it. The root issue are negations like "disable X".
ajuc
"DisablED" vs "disablE"
IanCal
I think a nicer framing is

Should this show the state or the action?

This gets messiest imo when it's a toggleable button like thing, or an unclear link. Buttons seem good candidates for "trigger an action", checkboxes instead suit "this is the state".

Gareth321
Simple solution: change the label on action.

"Flubber enabled" [toggle ON]

"Flubber disabled" [toggle OFF]

IanCal
I don't really like this as it's not clear to me until I use it that I see it's a changing label. I don't want to have to interact to discover what will happen if I do.

The toggle being off means it looks like "Flubber disabled: off" or "Flubber disabled: no" but it means "Flubber disabled: yes"

dusted
Flubber enabled [X]

Flubber disabled [ ] <-- Does that mean that flubber is not disabled ?

Never touch the label, and never tell state outside of the checkbox:

Flubber [X] <-- Clearly, flubber is enabled.

Flubber [ ] <-- Obviously, there's no flubber.

godelski
Wouldn't the confusion only exist if it was

Enable Flubber [X]

But not when labeled

Flubber Enabled [X]?

To me there problem here is understanding if the toggle is displaying a state or action because English is limited. But in the past tense version that is far less confusing because it clearly expresses that this is a state and cannot be an action (i.e. "Would you like to Flubber Enabled?" doesn't work nor does "Would you like to Enabled Flubber?" but "Would you like to Enable Flubber?" does). The "ed" matters as well as the word positions. The reason being is that the second word describes the state of the first which is why you can change it. In your example it is easy to understand with the checkbox but the thread at hand is about how toggle switches' visual appearance is confusing so your example is clearly not obvious (otherwise this thread wouldn't be on the front page). The idea of toggling the label means that there are now two indicators of __state__ that should verify one another and thus reduce confusion.

a9h74j
Maybe stop using necessary "preceeding" verbs and actions to indicate state, but use explicit ON or OFF to match the desired result?

It is common in telling someone how to use a UX that they need to "disable" X or Y option, but, again, that is to say that the intended state is on or off.

orthoxerox
"Flubber: disabled [__O] enabled"
4RealFreedom
I really like that. Do you know of a site that does this today?
Enginerrrd
I've definitely seen a couple of cookie toggles that worked this way. But, i can't remember which ones off-hand.
hnburnsy
love it but you will see dark patterns like...

"UnFlubberize:disabled [__O] enabled"

[deleted]
(comment deleted)
angoragoats
This is the worst possible solution because you're now showing the state and the action simultaneously, arguably making it less clear about the meaning of the toggle.

The ARIA guidelines for switches even have a big warning about not doing this[1].

[1] https://w3c.github.io/aria-practices/#switch

fortran77
If I saw "Flubber Disabled" with a toggle next to it that was "off", I'd turn it "on" to enable the "Flubber Disabled" feature.
mmis1000
I think checkboxes is 'the state to be if I click save'. I don't generally expect checkbox to change the state instantly if I don't click 'submit' or something similar.
IanCal
Interesting, I don't look at the same way - which is another reminder to me why good UX design is hard as my own interpretation of something as simple as a checkbox isn't universal.

On a similar note, I find it hard when I don't know if I need to save or submit.

scotty79
I'm also always looking for save button after I check some checkbox. Maybe that's why people move to toggles for changes that are immediate.

However when I make textual change and there's no save button I'm still confused.

There's no standard how to indicate imediate change in textbox.

mmis1000
I remembered that some sites use a small spinner on the edge of textarea or something similar to indicate "I am uploading your text to cloud / I am saving your text to disk".

I think it's a good design that tell users your changes are persisted "now" ?

And this can be probably applied to all options that take effects instantly.

scotty79
Good idea about small save indicator on every change.

Another idea:

When you start typing textarea visually changes style to indicate editing. Once you leave it it changes style back to indicate that this new content is written.

Optionally additionally while editing small X icon might show up and clicking it might cancel the change instead of saving it.

strken
If it's a switch, I don't understand why it can't be represented as a switch:

    Fnurbification disabled
             O
             |
    
    Fnurbification enabled
Of course, UX design metaphors based on actual mechanical devices aren't cool anymore, but a brave enough soul can ignore coolness in favour of functionality.
q3k
Even better:

    Fnurbification enabled
             |
             O
    
    Fnurbification disabled
:)
AndrewDucker
Light switches are on when they're in the down position.
jonwinstanley
Unless you have two switches for the same light so the on position depends on what position the other switch is in too
jonsen
Both switches should be turned 90 degrees and move horizontally.
gpderetta
luckily all light switches have a light indicator show the current status.
jameshart
Except when the bulb has gone. Which is the one time you really want to be sure the power is off.
gpderetta
In that case removing the broken bulb and sticking your fingers on the metal bits also works.
throwaway019254
> Light switches are on when they're in the down position.

This really depends on the part of the world you are living in.

When I was living in Central Europe the light switches were on when they were in the up position.

Edit: Even all my Canadian switches are like this. Up is on.

vinay427
The UK and many ex-colonies that also maintain plug/outlet switches seem to generally use down for on, while the US/Canada/Central Europe often use up for on.

Especially annoying are the posh toggles, unnecessarily popular in some European countries (e.g. CH) that don’t have any physical indicator of on-off status.

michaelscott
The lack of any affordance whatsoever on buttons, switches and appliances in Switzerland drives me absolutely insane
Digit-Al
This becomes confounded if you have multiple switches for the same light though.
scotty79
Maybe they should be installed sideways.
kortex
Here in USA, single-gang switches have "on" and "off" embossed on the switch, so the state is shown based on the position (oriented up is on). Multi-gang switches have no embossing.
vinay427
It’s fine for multi-way switches, and probably even better than confounded switches, but as I mentioned they’re unnecessarily common which in this case means that they’re often used (at least in some settings in CH) for single-switch setups as well. For instance, my apartment had around 8-10 push switches of this type, with only 1 that was a three-way switch.
glandium
And in other places (e.g. Japan), the switches are left/right. I think right is On.
lifthrasiir
Sometimes it can even be either way, because there are two switches and toggling one of them toggles the light in any case; they essentially act as a XOR circuit and are most commonly seen in corridors.
glandium
More like a not xor, since you typically need to have both in the same position, not in opposite positions.
Akronymus
Central europe here as well: We have light switches that are press to toggle and spring back in our home.
hutattedonmyarm
The apartment I live in has switches that turn the light on in its down position in some rooms and switches that turn the light of in its up position in other rooms. Fun!
Kubuxu
You can fix it quite easily by pulling out the whole switch and setting it in the box the other way.
hutattedonmyarm
But by now I've gotten so used to it that I don't want to :)
[deleted]
(comment deleted)
ilyt
Or when you cheaped out on workforce you could get some of them up, some of them down :D
Terretta
(A) What? Not.

Off: https://media.istockphoto.com/photos/light-switch-in-off-pos...

Also off: https://upload.wikimedia.org/wikipedia/commons/thumb/6/65/Ro...

Unless you mean this kind that offer either way: https://m.media-amazon.com/images/I/71BTb1oUUYS.jpg

(B) The standard three way* switch would like a word.

* Which actually means two switches (or more).

Izkata
Yeah, I've lived with dual switches my whole life. Hallway in my childhood home, the two entrances to my kitchen now. Also my bathroom switch is left/right. I had no idea "up is on/off" was even a thing until someone referenced it a few years ago (in my 30s).
latexr
It depends entirely on how they were mounted/wired and if the person doing it cared. Where I live the inconsistency is real, even inside a single home, though most people seem to not care. In my own home I fixed everything which was in the subjectively wrong position, it was trivial to do.
KineticLensman
Yes. An electrician re-wiring my kitchen had three adjacent switches differently up / down when all off. He happily redid them when asked, but clearly himself didn't care about the consistency.
l-
The analogous case being a horizontal circuit laying on a table with the crossbar switch up in the air causing an open circuit & being down closing it.
numpad0
I think the way it's done in aerospace is

      FNURB 
  NORM  c- ALTN
or else

      FNURB 
      [   ]  < normally blank
      [   ]  < shows ALTN when selected
ilyt
It would probably have TEST as 3rd option
xxs
enabled should be the top (vertically) choice
tobz1000
Most comments are in favour of the former, but we've been trained by every media player UI to understand that a button with a pause symbol means that the media is currently playing.
dfxm12
It's worth noting that physical media players (VCRs, CD players, Tape players) usually have separate play and pause buttons. The Winamp default skin did also. Most of us were trained to expect that before contemporary media players started showing up.

I think it's also worth noting that it is usually very obvious what state a media player is in, so it makes sense we would have different expectations from that UI vs one where we aren't sure of the current state.

ilyt
Tape players have it because buttons were used to physically actuate controls of the deck.

It was easier to have "stop" be mechanics to disengage head, "play" to engage head" and "pause" being just on/off switch for the motor than trying to merge play/pause into 1.

> Most of us were trained to expect that before contemporary media players started showing up.

CD players started getting play/pause precisely because they didn't need to. Most VCRs also had digital controls (coz moving mechanisms via push of button would be harder with big tapes and heads) and they also did often have play/pause integrated.

Some opted for copying tape 1:1, some merged play/pause into one button, it certainly wasnt that all of them had separate pause.

swores
> It's worth noting that physical media players (VCRs, CD players, Tape players) usually have separate play and pause buttons.

Anecdotally (in UK&EU) every old tape, CD, or VCR player I ever had combined play and pause on a single button, even devices where there was no screen to show current state it was just the norm that the same button toggles the current state.

francisofascii
> a pause symbol means that the media is currently playing

Except when it isn't playing. It get confusing/frustrating when dealing with low volume, buggy software like the Iphone Podcasts app or Bluetooth. Then you think, oh, maybe it's in a paused state.

zestyping
Media players should have a "playing" indicator that is separate from the play/pause control. Not just because of the ambiguity between state and action, but also because there is difference between the requested state and the actual state!

A media player can be in the "user wants to play" state and not be playing, because buffering is taking place. This is a very common state, yet all the media players I've seen have an ambiguous or confusing display during this state.

ilyt
It's very easy to reconcile. If you have to have inverse logic in UI (which is wrong, but designers gonna design despise logic or usability), you can just have "Enable"/"Disable" but use other hint showing the current state, say paint the disabled ones red and enabled ones green .

Non-default state should also be indicated

mensetmanusman
As a user who switches between apps and there isn’t consensus on this… it’s confusing as hell.
naasking
First, checkboxes and toggles are not buttons, so that's a slightly deceptive way to describe it. If you use "checkbox" instead, it's immediately clear who's right:

> and the people who think the [checkbox/toggle] should show what state it will change to when activated

These people are wrong. The simplest thing should be the default and this adds extra indirection (projecting future state from current state), therefore it's not the simplest, therefore it's wrong.

Unless of course you mean something strange by "activated".

a9h74j
Well put. Could adding either the words: "Current state:" or "Action:" clarify this?

With toggles, I'd almost rather see them aligned center with explicit state description to either side.

denton-scratch
> two conflicting schools

Three, apparently: there are the people (such as me) who think the button should "show" what it does when you click it. It shouldn't indicate anything else (except it's enabled/disabled state, i.e. whether you are allowed to click it). Button text should be constant. If you need an indicator, that should be another widget.

janalsncm
This UX headache turns into an evil dark pattern real quick when it’s combined with privacy toggles that are conveniently never defaulted to the way you would want them.

The less cynical take is that you only ever interact with privacy controls when they’re wrong, and the subset of those which are confusing are the most salient.

mhitza
Just the other day I've encountered a cookie modal, where the enabled option was grayed out and when disabled it was colored. Only noticed this because the required cookies toggle was obviously on (though gray in color). For someone in a hurry (like we are all when dismissing those modals), you would expect to gray those out, which would actually make you opt-in to all those advertising cookies. Talk about dark patterns.
eloff
Do you remember what site that was on? I’d like to blog about that one.
mhitza
Unfortunately no, although I'm sure it must have been some news website that popped up in /r/europe or /r/worldnews
Tha_14
> Just the other day I've encountered a cookie modal, where the enabled option was grayed out and when disabled it was colored. Only noticed this because the required cookies toggle was obviously on (though gray in color). For someone in a hurry (like we are all when dismissing those modals), you would expect to gray those out, which would actually make you opt-in to all those advertising cookies. Talk about dark patterns.

I realized the same pattern but in reverse in my phone provider's app. When you're making a payment with your credit/debit card, there is a toggle that you can turn on for them to tokenize your card. By default, the toggle is to the left side and it's colored light blue. When you toggle it to the right it become gray. I believe they have done it on purpose to confuse prople who don't want their card tokenized.

j33zusjuice
Why would anyone not want it tokenized?
brookst
Also curious. The only thing I can imagine is wanting to call customer service and have them say “you paid your last bill with the CC ending in 1234” and knowing which of your card that is? Seems like a stretch.
Yizahi
I've previously assumed that the choice there is either:

a) don't save CC info at all

b) save CC info in tokenized form (whatever that means)

And since I never save CC info on websites (only in the phone wallet feature) I've always rejected these "tokenized" prompts. But it seems I need to research this thing more next time.

Tha_14
> I've previously assumed that the choice there is either:

> a) don't save CC info at all

> b) save CC info in tokenized form (whatever that means)

> And since I never save CC info on websites (only in the phone wallet feature) I've always rejected these "tokenized" prompts. But it seems I need to research this thing more next time.

Tokenization means that the payment processor saves your cc information for "easier" use when you make purchases/pay bills in the future. The seller/service provider can of course use that token to charge you anytime they want. I hope this helps with understanding how it works(and why I am hesitant to allow tokenization of my cards).

a9h74j
If I understand, bad (against user interest) defaults can be called a dark pattern, but shouldn't purposely misleading state indication also deserve the direct label: deceptive practice?
denton-scratch
> the enabled option was grayed out and when disabled it was colored

In the old, default browser UI, buttons had black labels when enabled, and grey ones when disabled.

Then web designers started making button widgets that looked "cooler" than button elements. Then they realized that they could use the new "buttons" to make indicators as well; so they repurposed the enabled/disabled idiom to mean instead "on/off" or "yes/no". So now the idiom is ambiguous.

If you want a dual-purpose button/indicator, emulate those old keyboards that had an on/off neon in the CAPS-lock key. I prefer a separate indicator, but at least those old CAPS-locks were ergonomically unambiguous.

dspillett
> privacy toggles that are conveniently never defaulted to the way you would want them

Or conveniently defaulted the way you want them, but with wording and other visual clues twisted in such a way to make you question that and maybe accidentally opt in.

artificialLimbs
I've been winding down my Facebook over the past year or so. Unliking things, unfriending friends, and deleting posts. If you try to unfollow a page on Facebook, the "Unfollow this page" button is turned off, and you must turn it on/check the button (which changes it from gray to blue) to UNfollow the page. One of the many reasons I've been winding down my Facebook.
Existenceblinks
I think it shouldn't include the redundant semantic in the label.

  [ ] fnurbification
  [x] fnurbification
or

  [*enabled* | disabled] fnurbification
  [enabled | *disabled*] fnurbification
Light up the active one.
saagarjha
Checkboxes stay winning.
numpad0
It's not when desirability of fnurbification negatively correlates to other items, i.e. when following is normal config:

  [X] perform deconbinaturation 
  [X] disable fnurbification 
  [X] enable entrapollation
... in this case there is a reason to make it a "positive-disable".
ilyt
Nope, just mark which config is default and add tooltip explaining to user why it might need to be changed.

Aiming for all options to be "on" or "off" is some pedantic nightmare that makes settings harder to navigate

bentcorner
> Aiming for all options to be "on" or "off" is some pedantic nightmare that makes settings harder to navigate

This probably stems from config files or in-app defaults where a feature is default-on and so the existence of a value means something is disabled. And then some dev comes along and mindlessly transcribes a bunch of boolean flags into a settings menu and here we are.

amelius
To make matters worse, a disabled checkbox is one you can't toggle.
Existenceblinks
Not sure we are on the same page, the two lines is only for demonstration, the real ui is going to have that one line at a time. And the latter is custom radio button, I think it's up to 5 short name items before consider making it a dropdown.
stranded22
So, radio boxes then…
Existenceblinks
I think rectangle switch with active light on one end is good. I believe the confused one people talking about is the rounded slide toggle whose body color is used as status (the bolt head left right is equivalent to meaning nothing)
rjmunro
You mean:

  ( ) enable fnurbification
  (o) disable fnurbification
mildchalupa
There are many instances where the default is set at enable fnurbifucation with white text on a black background. Disable is shown as black text on a white background. When you change the state the text and background color inverts.

There is no way of knowing for certain what position is on and what is off without assuming that the first displayed state is on.

I believe recently I setup a nest with this issue. There is no way of knowing what is specifically selected unless there are three options. With three exclusive options you can compare to determine what the current state is because two of them will look the same thus must be off.

Ti-89 93... calculator settings can have this issue but some of the options have 3+ states and once you see the schema it's quite easy to deal with.

i_am_proteus
Consider the UI design from the perspective of someone whose goal is to make it less obvious for how the user can disable cookies, sorry, fnurbification, while still technically providing the user with the option to do so.
saxelsen
I honestly always test this with with video chat Mute buttons. I feel like it is only recently that UX designers designed a way to show that you are muted that is different from the Mute switch, which is a complete guess as to what state you are in.
seanhunter
Video chat mute is one of the worst offenders. If I recall correctly MS Teams behaves the exact opposite of zoom using the same ux.
climb_stealth
Thank you for putting this into words! It gets worse when it is for handling destructive actions. And it is not clear which way it is or it isn't destroying things. Actual nightmare material.
RobMurray
It's very common for developers to make accessibility worse by doing things like this. I have seen things where the two states to a screen reader are something like: "disable foo toggle button pressed" and "enable foo toggle button not pressed". Why not just a checkbox labeled "foo"?
[deleted]
(comment deleted)
Terretta
Bethesda (e.g. Fallout) are masters of the label as current state versus label as next state paradox.

On Fallout 76's "PIP Boy" UI, button tips for things that toggle or rotate settings like "(X) Allow Friends Only" arbitrarily mix states and actions, in the same UI!

That particular option is on the Private World creator and the only way to figure out which it is is to create a world and see who can join. There are many such examples with several buttons/action/states listed where some work one way and others the other. It's so bananas it's almost endearing.

koonsolo
For the second case the play-pause button has the same problem: what does the 'play' button mean? That it's currently playing, or that when you click it, it will play? Same with paused. Is it paused now or does it pause when I click it?
xmcqdpt2
That one wouldn't be confusing if people didn't attempt to save space by making it one button.

The tape recorders, vcr and dvd players I've seen mostly have them on two different buttons: pause which stops the current recording or playback and separate play and record buttons. There is nothing confusing to PLAY / RECORD / STOP.

Although I guess sometimes you have a joint pause play button especially on tv remotes and those ARE confusing.

ETA: apparently HN doesn't like the pause button emoji so i had to use text.

Sohcahtoa82
> ETA: apparently HN doesn't like the pause button emoji so i had to use text.

HN doesn't like ANY emojis.

Here's a smiling face, crying face, and elephant:

You'll have to take my word for it that I actually put them in my comment.

ilyt
In 2000's the "is playing" would be just "button looks pressed in", and same for "is paused", but today designers hate usability.
saiya-jin
Another version of hell is a checkbox being replaced by 2 radio boxes. But on page load none is selected, so UX changed 2-state piece for 3-state one (a small win is if they are at least grouped together so only 1 can be selected).
temp2022account
Good design is always hard to find, my personal solution would be a drop-down with the title: "fnurbification" and the options "Enabled" and "Disabled". More systems ought to be built like this, ambiguity is a black check for later economic loss.
ilyt 

    fnurbification  [X]
is not ambiguous. Drop downs for on/off is pure waste
dzhiurgis
Ditto. IMO toggles are the best option to simplify small dropdowns.
rr888
fnurbification: Off [ O] On
sinuhe69
For me, it’s quite clear in the reading, though. You have to read as it presented (label + switch).

For example:

  vSync ==> [On]

  vSync [Off] <==
I honestly can’t think to read it otherwise.

For the negative labeling, it’s of course unfortunate. But it’s in general the case for all negation. Thus, I try to avoid using negation when ever possible.

Lendal
You're mixing two different concepts. One is how to design a graphical gadget, which is a problem for front-end art work. Another is how a boolean variable should be implemented, a problem for your back-end logic. Computer-engineering ancient wisdom says always use positive logic. If you have a choice, never label a boolean something as 'disable', always 'enable'. Use positive logic, avoid negative logic.
seanhunter
Of course. I’m not saying it’s good I’m describing stuff that I see widely in apps and sites I use.

3) You see a toggle switch. It is labeled “Fnurbification”. It is set to “off”.

You want fnurbification. Do you flip the switch?

As we’ve established in 1 & 2 if you know that flipping the switch won’t change the label then clearly the label describes the thing so you should flip it.

If on the other hand flipping the switch is going to change the label then we’ve established that the label probably describes the current state. Flipping it would probably change the label to something like “Disable Fnurbification” and turn it off. So you should leave it off so fnurbification remains on.

But this is your first time using this app. How do you know whether or not the label is going to change? You could toggle the switch, but what happens if the action of toggling the switch is expensive or safety-critical?

4) Let’s raise the stakes. You see a switch. It is set to off. It says “Nuclear reactor safety protocol”. You want a safe nuclear reactor don’t you? Do you switch on or leave it off?

ilyt
This should be just

    Fnurbification  [ON|off]
or

    Fnurbification  [X]
Maybe add some indication which is the default. Bonus points for actual context of the function when you hover over it.

Checkbox is fine, toggle switch is also fine as meaning is clear in both cases.

Every other solution should lead to whoever responsible for it being fired

4RealFreedom
This can lead to additional problems. Say Fnurbification is a setting in code wrapped in an if block. Great, on or off is easy to follow. Now say the Disable Fnurbification is what is actually in code. Now, when someone has a problem with Fnurbification, you have to map state back and see that the inverse was coded for the IU and follow that down the stack. Don't even get me started on defaults. There is no good/easy answer here.
jefftk
There is an easy answer: "Disable Fnurbification" is not what should be in the code. Present the right interface to the user, and fix the code when practical. Presenting something backwards to the user only makes it harder to fix later.
4RealFreedom
I deal with hundreds of these types of selectors from some inherited code. When a disable changes 2 lines of code to wrap functionality in an if block v adding many scattered if blocks to accommodate the enable case, I'll probably go with the low code solution. If I can easily accommodate enables then sure but it's just not always that easy.
jefftk
This is just about what to call the variable. Instead of:

    if disable_foo:
      ...
I'm recommending:

    if not enable_foo:
      ...
soiler
there is an easy answer if your code isn't written in a way that obfuscates its functionality to the maintainer...
account42
The way your code is structured should never dictate the user interface. If that is inconvenient, adjust the code not the UI.
jen20
This depends on whether the goal is transparency and clarity, or tricking users into enabling yet more “telemetry” surely?
layer8
> Fnurbification [X]

Actually, that should be:

  [x] Fnurbification
j33zusjuice
Why? It feels better on the right, imo. It’s more natural, I see what it is, and then decide at the end to select or deselect. If it’s on the left, I now have to return to the beginning of the word. It’s not very natural.
wiradikusuma
I think it looks nicer if you have few elements with varying width:

[x] bla

[ ] this is a very long label

[ ] lorem ipsum

layer8
Yes, it’s the same reason why bullet lists have the bullet on the left side.
chaorace
More broadly, this is a consequence of English being a LTR language. The eye scans from left to right when reading these languages, so one naturally wants to place important visual symbols (bullets, controls, etc.) firstmost where they'll offer maximum contextual impact for the proceeding information.

The fixed-width nature of these elements is more of an afterthought that emerges because neat grids make information easier to parse and are generally considered to be visually pleasing. In RTL languages, the movement of the eye is mirrored, so the natural position of these elements also gets mirrored to the right-hand side. Of course, the fixed-width nature does not change because the instinct to craft neat grids exists regardless of directionality.

Recently, however, we have begun to see certain touch-based interfaces adopt right-aligned controls specifically, even in LTR configurations. This evolved to compensate for the fact that most people are right-handed and generally cannot reach across the width of a modern touchscreen one-handed. It's effectively a concession to accessibility and is best implemented as a toggleable feature to avoid disadvantaging left-handed users.

glitchc
Looks nicer but is less user-friendly.
Tagbert
More user friendly for parsing a list of different options.
glitchc
I disagree and I'm a user.

Buttons and toggles along the right margin and text on the left works for me. I prefer to read first what I'm turning on or off.

TheAngush
There's a distinction between user-friendly and you-friendly, regardless of your individual status as a user.
cyanydeez
Easier to line up check boxes on left
zestyping
The checkbox is closer to the text on the left. If it's on the right, there will be a gap that varies with the length of the longest item, making it harder to line up with its associated item.
dotancohen
The problem is that in English "on" and "off" are both adverbs and adjectives.

A designer that I once worked with came up with a terrific toggle switch, really the only one that works as well as the simple checkbox in my opinion:

https://ux.stackexchange.com/questions/1318/should-a-toggle-...

mrguyorama
But but but but skeumorphism is unfashionable and apple said it wasn't good anymore!!!!

You are supposed to design your UI as if it was made in ten minutes by a lazy high schooler making a powerpoint with all the defaults and just bulleted text on a blank background.

sebastianconcpt
Good point.

Knowing how it ended is killing me, quick question, at the end did you got fnurbificated or not?

shreyshnaccount
A checkbox could have the same issues. Both ust represent binary state
shreyshnaccount
A checkbox could have the same issues. Both just represent binary state
feintruled
Imagining a meme of the sweating button push guy, only this time it's a single (lit) button and it's marked 'disable self-destruct'
animuchan
This is literally in Brave's settings: you see the "Block sites from autoplaying videos" and next to it, a switch that's turned off. And you think "Okay then, autoplay blocking must be off", but nope! Makes me a little less sane every time I use it, this UI.
didntreadarticl
People worry too much about fnurbification, I find it doesnt make much difference at the end of the day
hk1337
That's like this function in this legacy code I am working on has an alert function for creating the bootstrap alerts with options like "dismissible_off" and "autohide_off" instead of just "dismissible" and "autohide", also they're just integer values (0 or 1) instead of boolean. I have to think about it way too much when I use it wondering if I have the setting correct.
hermitcrab
I'm with you. I rarely know if the label refers to the current state or what will happen if I click it. Very confusing. Checkboxes are much better.
mmcnl
Fair enough, but this is also true for checkboxes.
conradludgate
I used my partners samsung recently. I needed to receive a call on her phone. It was muted and I wanted to turn the volume on.

In the settings drop down was a greyed out button with a volume icon and the text "Mute". Does clicking that enable the mute setting?

Turns out that just means it is muted. Checking the button made it update the text to "Sound". Such an awful design IMO.

It wouldn't be so bad if it was

Mute <slider> Sound

But that takes up far too much UI space in the settings dropdown intended for quick actions

lgreiv
To me, the semantic difference between the two is that I expect a toggle to cause an immediate effect whereas a checkbox merely holds the value to be applied later.

Applied to a client/server web application, I would expect a toggle to immediately cause a request to the backend. I’d expect a checkbox to be used in a form which is sent as a whole on submit.

rhn_mk1
I don't have that expectation. What caused you to have it?
SSLy
It's cultural, check boxes come from boring and usually not greatly designed universe of Windows and Linux desktops, toggles come from immediacy of iOS devices.
alxlaz
I know I'm old but I still see light switches all around me. Doesn't anyone flip them anymore?

It's cultural but this has nothing to do with Windows, Linux, and iOS. You flip a switch, the light comes on immediately. This is about the immediacy of switches, not iOS devices.

hgsgm
No, we use apps to control lights now.
em500
I'm guessing that historically toggle switches would (immediately) close some electric circuit, whereas checkboxes were used to mark things as done on some paper list.
hgsgm
Checkboxes were used to indicate a request in a <form> that you later <submit>
[deleted]
(comment deleted)
reacweb
Maybe we should use toggle switch only when the effect is immediately visible.
lgreiv
It is the metaphors that they apply, a toggle mimics a switch (e.g. a light switch) while a checkbox mimics it’s own paper counterpart.
Existenceblinks
Yeah, UI design often rely on familiarity and it's going to confuse some % of minority because people's experience are different (been trained with different environment and situation in life, plus arbitrary brain chemical etc)
leokennis
I do have (or at least understand) that expectation.

Historically (90's, early 00's) in Windows, which had 95% of market share, almost any settings screen would only apply the settings you changed after you pressed the "Apply" button (apply the settings and stay in the screen) or "Save" (apply the settings and close the screen).

I'm not sure how Mac OS X fared in that regard. But, for some older people, "click an option and it's immediately active" is not how it was in the past.

systoll
I think that might be the underlying… misattribution(?).

Almost no macOS screens have ever worked like that. Their interface guidelines have always recommended against it.

> ...all changes that a user enters in a dialog box should appear to take effect immediately whenever possible. — macOS 9 guidelines: http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

Following Apple’s sensibilities will get you both toggle switches and instant changes, though I’m not sure there's a connection within any single interface.

xmcqdpt2
You are right. I just had to go back and look at some OS8 screenshots to confirm and indeed they don't have save/apply anywhere

you may not like it but this is what peak UX looks like

https://guidebookgallery.org/screenshots/macos80

crazygringo
I think most of what you're referring to was Control Panel.

Control Panel was unique in settings applying immediately. Pretty much every app's preferences (or other settings) were a modal dialog with OK/Cancel, however.

So it was a step forwards when iOS's Settings app changed from checkboxes to toggles, because this reflected the immediate change. And now with Ventura, macOS has finally caught up as well.

godshatter
I mourn the loss of apply and save buttons in settings screens. It's supposed to act as a transaction does in a database. You set the controls to your preferred state, click apply, and get an error message that setting Y cannot be active when setting X is. So you fix your adjustments and try again until you get it right. Without this, you've already set X, and Y is either still active or turning on X turned it off, so you're in a state you didn't want to be in and bad things may have already happened.

Timing may also be a problem. Settings might affect each other, or you may want to change a bunch of settings so that they all happen at once. You can also run into problems where you want to flip setting A from on to off and flip setting B from off to on, but they can't both be off or both be on at the same time.

My biggest annoyance though is that I have decades of doing it one way, and now it's flipped. Automatic saving on Microsoft Word when you're editing a file on OneDrive still annoys me. No longer can I take an older copy of something, change a few things, and save it as a new document. I've just managed to mangle the original document through sheer muscle memory (from five minutes ago when I did the same thing in the same copy of word to a document on my disk drive).

[deleted]
(comment deleted)
l-
Storing the mechanical action is an added expense. Pure Latin character based mark additions (& reversals) could include o -> p, or q along with font dependent n to m, V to W, F to E; l or I to B, D, E, F, H, K, L, M, P, t or T.
berkut
While I think that's somewhat true to a degree, I think that might be largely because where checkboxes are used (on desktop), there are normally OK or Apply buttons which do the actual action, whereas where toggles are used, things are normally "live", and so they don't have OK or Apply buttons...
ilyt
I'd expect it to work on submission only if I saw actual submit button, regardless of what else is in config. I also strongly dislike apps that do the instant thing, coz there is no way to undo something if I made a mistake (say removed some value that I shouldn't)
crazygringo
This is exactly it, 100%.

But it's taken some time for UX paradigms to coalesce around this -- simply because checkboxes used to be used for both, until Apple "invented" toggles for instantly-applied settings in iOS.

Now that Apple finally implemented toggles in System Settings in macOS Ventura, the paradigm is largely consistent in desktop software on Macs. Toggles apply a setting instantly, while checkboxes are used within an "OK/Cancel" dialog.

But I think because it's taken so long for toggles to "spread", a lot of users and developers have an instinctual understanding that toggle = instant, but haven't always been able to articulate it.

jayd16
What is your expected UX for a toggle with poor network reliability?
lgreiv
I have seen several variations that I found consistent with the metaphor of a switch.

Broadly, these could be divided in implementations that offered a loading state (switch goes transparent until persisted, overlaid spinner etc.) and implementations that flicked the switch back when the request failed and provided a very noticeable status update (hint, animation, growl).

My preference for systems that work with unreliable persistence is the former, albeit that is purely personal and not founded in a deeper rationale.

fsckboy
the left-right slidey things were an Apple affectation, no doubt introduced just to be different, after all, Apples were for the rest of us. We're different.

they have much less usability

what stinks about them is you can never quite figure out or remember if you're supposed to just tap, only tap on the "other end", or actually slide the slider.

saurik
FWIW, the ones on iOS have always been something you could drag. As far as I have ever understood, all of the UI controls on iOS were designed to be skeuomorphic in a way that directly made sense for someone futzing with their fingers: you push buttons, you scroll a WHEEL to work with selection boxes, and flip switches to toggle options (which also, notably and at the time almost specifically on Apple products, take place immediately with no concept of "Apply", and aren't part of a "form" metaphor).
baggsie
Touch requires a bigger target area and big checkboxes look terrible.
ComodoHacker
the checkbox itself doesn't have to be as big as its hitbox.
onion2k
One thing that you lose if you replace checkboxes with toggle switches, at least on webpages, is the third 'indeterminate' state that JavaScript offers. https://css-tricks.com/indeterminate-checkboxes/
stonecharioteer
I've never understood what that state is supposed to indicate. It only makes sense when the checkbox has nested checkboxes underneath and an indeterminate state only indicates that the user has some of the children selected. But as a user I'd never be able to select this indeterminate state, since, by definition, it is indeterminate. for such scenarios, I'm not sure what is good design.
leokennis
Food ordering screen:

[ ] Add sauces to my food

  [ ] Mayonnaise

  [ ] Ketchup

  [ ] XO Sauce
If I want all sauces I click the first box:

[v] Add sauces to my food

  [v] Mayonnaise

  [v] Ketchup

  [v] XO Sauce
If I only want Ketchup and click that:

[-] Add sauces to my food

  [ ] Mayonnaise

  [v] Ketchup

  [ ] XO Sauce
scrollaway
Better ordering screen:

    Extra sauces (1 selected):
      [ ] Mayonnaise
      [v] Ketchup
      [ ] XO Sauce
I understand what indeterminate checkboxes are, but I don't remember them ever actually making sense anywhere I found them.
msh
When well implemented the clicking [-] would unselect all and clicking again select all.

It does not matter with 3 options and 1 selected, but its nice if its 20 options and 7 random ones selected.

[deleted]
(comment deleted)
nitwit005
They're optimizing for the website looking cool and trendy, which is an ever shifting standard.
jhanschoo
I think toggle switch has a different connotation from checkboxes.

Checkboxes were primarily designed for questions where a user wants to choose a subset of related options for the same topic. (e.g. Which colors are acceptable to you? Red yes/no, Blue yes/no, Green yes/no)

The toggle switch connotes an A/B answer to a single question. (e.g. Dark theme? yes/no)

hknmtt
YES, I hate these things with vigour!
thewebcount
This is kind of embarrassing to admit, but I couldn’t figure out how to change the state of a toggle switch for a really long time. I kept trying to slide the switch left or right. Sometimes it worked, but often it didn’t. It wasn’t until I had been using an iPhone for a couple years that I discovered you’re just supposed to press it, not slide it. What a stupid design.
bbx
On iOS, you can either press it or slide it.

The problem is that a lot of websites have started using them and only implement the click/tap event, not the mouse press and move event, or the slide event. So they end up being quite misleading.

boomboomsubban
Similar. In my defense, lock screens on phones used to have a toggle switch you needed to slide.
Terretta
Those were not a toggle. They were a sliding latch:

https://i5.walmartimages.com/asr/5cd445f6-b24c-4e39-8c10-0a0...

ilyt
And UIs started using sliding latch icon for toggles, which is the point of contention here
Terretta
These toggles descend from dip switches, not latches.

Consumer electronics had dip switches behind precisely the graphical design Apple introduced for these toggles.

Some of the early skeuomorphic designs (this is not Apple, nor early, just illustrative) made this more obvious:

https://cdn.dribbble.com/users/291697/screenshots/1027928/on...

Another common implementation looks like a two or more position slider, but still not a latch:

https://alphauniverse.media.zestyio.com/gmaster-sel85f14gm-l...

judofyr
> It wasn’t until I had been using an iPhone for a couple years that I discovered you’re just supposed to press it, not slide it.

Huh? On the iPhone you've always been able to slide it.

I blame this on all the other implementation which copied the switch design, but didn't bother to implement sliding…

Terretta
Just confirmed, on 16.3 still slides, you can even do it partially/slowly. Readily accessible one is settings airplane mode, first setting in settings.

Absence of verb in label makes it clear what it is.

Meanwhile, on Kindle, it shows a black airplane in a white circle labeled "Off" and a white airplane in a black circle labeled "On". This is a recent update from before where the first was an airplane with a slash through it for Off. In both cases, Cell/WiFi is on when labeled Off, network+radios are on when icon was airplane with a slash through it labeled off.

stefncb
I have an iPad. There seem to be two kinds of toggle switches in the native apple apps; one of them slides and animates, but the other one can only be pressed and it doesn't animate the transition. The latter is less common, but I've seen both in the same app before (settings I think).

It's likely a strange bug, but I think it's relevant since you can't _always_ slide it.

lawkwok
I’ve always liked Apple’s implementation because the slider has a temporal state.

Airplane mode used to take a a couple seconds to enable so the toggle felt “stickier” to toggle. When you tapped on the toggle, the round button elongated and stayed in the middle for a split second before hitting the right side boundary of the toggle.

eproxus
That seems to no longer be the case. Toggling Bluetooth on iOS 16.2 on an iPhone 14 Pro replaces the slider with a spinner, and it even flickers when turned back on.

Also, the sliding only works correctly if you press and hold and then start sliding. If you swipe, it toggles regardless of which direction you swipe.

claviska
This started when people discovered they could style <input type=checkbox> to look like a switch with pure CSS. (And, as a component library author, I can confirm it continues because we, perhaps lazily, don’t bother implementing the slide.)
Existenceblinks
The problem is the popular toggle switch should be like a extension socket switch, not the slide body color as status. The head of each end should be lighted up, not the body.
kzrdude
I happily confirmed that the settings app in GNOME Shell 42 implements sliding correctly, it works fine.. so I tried slide, slide, slide and a little bit more and the gnome-shell process crashed :)
deelly
Sorry, but why this is so funny?
LudwigNagasena
Because it’s 2023 and we can’t get basic UI that works properly?
kzrdude
Crashing is funny. In this case, it's hopefully because of the thing it toggled and not the UI. (I was toggling "allow overamplification" in the sound settings).

Maybe this is the relevant line of the crash log: Object Gio.DBusProxy (0x55e4d0f30a90), has been already deallocated

everybodyknows
Sure sounds like a race. Building race-free software is hard, disciplined work, and may require blocking proposals for "hot" new features. So the cooler heads tend to lose those skirmishes, on either a FOSS or commercial battleground.
nix0n
> In this case, it's hopefully because of the thing it toggled and not the UI.

I think this is true, since I get Gnome crashes in the bluetooth settings and nowhere else.

sideshowb
Microwave ovens agree with you
efreak
The 1 button instantly starting the microwave for 1 minute annoys me often. I want to set the timer for 15 seconds so I can walk away. For 1 minute, double-tapping the 30s button is sufficient.

The real annoyance, though, is that pressing cancel/off does absolutely nothing if the microwave is being used as a timer (without the microwave itself running). When the timer beeps, my first thought is to press cancel/off. Then press it again a few times, because it's still beeping. Then I remember that there's a dedicated button (somewhere in the middle of the panel, labeled with small text) to cancel the timer.

ilyt
Well, they took 42 versions to fuck up basic shit, it is hilariously incompetent
kzrdude
Naw I wanted to share this without it turning into that kind of mudslinging.

Something about desktops that never get complaints vs desktops that people actually use.

IshKebab
I think people have far more complaints about Gnome than Mac and far more people use the latter.
pas
because endless years are going into a fundamentally subpar system (GTK written in C and JS, because gnome devs were not edgy enough with just C, and they are obviously too cool for TS)
QUrprUd1nCeicw
Typescript and Rust didn't exist in the late 90s when GNOME was created.
pas
Gnome continues to be created even today with C and JS.

After a few years of Windows, this week I installed Ubuntu again, and it's full of crazy bugs. Though no crashes yet! So at least they improved on that a lot.

meigwilym
Years ago I built a cms using these sliders, and one of the users was having problems. I double checked and it worked fine. So I said I'd watch him use it to see what was wrong. He clicked the slider and dragged it to the other side. My jQuery code was listening for 'click' events, which was the source of the bug. Since then I'm careful to use them "properly".
axismundi
[ ] Fnurbication

When enabled, created nurbs are automatically converted into fluffy nurbs.

gorbachev
UI designers need to stop following fads. You see bad ideas spread like forest fires all the time.
bandie91
"the right side is on" – i'm afraid to bring up, is it so in RTL locales too?
Adverblessly
Randomly checking one of my apps, the answer is "no" (i.e. the left side is on), but if you are looking at some random website that appears to have been localized, there isn't really any way of judging if they decided to switch the toggle direction or not.
cik
I'm glad that you know the right is on.. but I don't. I live in a country with a right to left language system. Things locally, done in the local language are right side is off. Things internationally behave the way you've mentioned. Checkboxes are infinitely better, because they're not language dependent.

This is an incredible source of frustration - and one that comes up often. As a native speaker of multiple languages, I always pause and do a double-take in order to actually "see" the language, given that I usually don't notice.

kzrdude
I thought the color/highlight was the only hint, it wasn't clear to me if left or right is on.
drchaim
also me, I always double check. when there is no label: On/Off is even worst.
captainmuon
Honestly, I think it is just a trend. It started with the iOS settings UI, everybody copied it and is still copying it almost 15 years later. Look at the settings in Windows, Android, macOS (Ventura), Gnome. List/Detail view, and the detail pane is itself a list of mostly switches.

One downside is as you mentioned the confusion whether it is on or off (although nowadays most UIs make it double clear with color and some with additional text). But also because the switch is on the right hand side, it is further away from the text, and is visually inconsistent with radio boxes. And it is part of this "iOS settings" design language which itself is problematic, because it doesn't try to have specialized panes for each setting but crams everything into lists. (This is not the fault of the toggle, but how it is used.)

One point in defense of the toggle is maybe that it is not clear to everybody that you can usually click the text on a checkbox, making the click target rather small. But you generally can't click the text on a toggle, so it is moot.

benj111
I assume it's part of the 'make everything usable on a phone' thing, regardless of whether you are actually using a phone, so the thing that only contains a half screen of information is now spread over 4 screens.

But then you also have the designers that like to make things pretty, rather than give you any hint that some text is in fact clickable.