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

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?

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

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.

  [ ] Foo
  *Foo is disabled*

  [X] Foo
  *Foo is enabled*

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

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

The language even for discussing this is tiring to read…

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

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

    [X] Send notifications

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.

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

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.

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.

https://pbfcomics.com/comics/skub/

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

"Flubber enabled" [toggle ON]

"Flubber disabled" [toggle OFF]

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.

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.

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.

"UnFlubberize:disabled [__O] enabled"

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

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

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

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

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.

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.

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.

    Fnurbification disabled
             O
             |
    
    Fnurbification enabled

    Fnurbification enabled
             |
             O
    
    Fnurbification disabled

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.

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.

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

      FNURB 
  NORM  c- ALTN

      FNURB 
      [   ]  < normally blank
      [   ]  < shows ALTN when selected

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.

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.

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.

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.

Non-default state should also be indicated

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

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

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.

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.

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.

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.

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

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.

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.

  [ ] fnurbification
  [x] fnurbification

  [*enabled* | disabled] fnurbification
  [enabled | *disabled*] fnurbification

  [X] perform deconbinaturation 
  [X] disable fnurbification 
  [X] enable entrapollation

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.

  ( ) enable fnurbification
  (o) disable fnurbification

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.

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.

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

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

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.

    fnurbification  [X]

For example:

  vSync ==> [On]

  vSync [Off] <==

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.

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?

    Fnurbification  [ON|off]

    Fnurbification  [X]

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

    if disable_foo:
      ...

    if not enable_foo:
      ...

Actually, that should be:

  [x] Fnurbification

[x] bla

[ ] this is a very long label

[ ] lorem ipsum

For RTL languages, everything is simply mirrored though: https://learn.microsoft.com/en-us/globalization/localizabili... It doesn’t change the general argument.

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.

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.

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

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.

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

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