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?

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

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.

It can be ambiguous as to whether the label describes the current state, or the future effect of pushing the toggle.

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

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

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…

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.

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

Too verbose.

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