Toggles Considered Harmful

BugsJustFindMe

They created toggles to differentiate between settings that take place immediately vs being deferred until a later Save action. If you accept that premise (you might not!) then the problem isn't toggles per se but that the toggles are displayed in a way that makes the current and alternate states ambiguous. In case you're wondering, macOS didn't have them until they started fusing it with iOS.

cbarrick

The use of grayscale is a bit disingenuous. Gray is not the default color theme on macOS. The default is blue. So the criticism about using right/left to distinguish on/off doesn't really apply. In reality, the use of color disambiguates the on and off states. Just like the physical toggle example it's being compared against. That's not to say there aren't problems with toggles, but the article's core argument falls apart if you use any color theme other than gray.

dlcarrier

I always wondered why web pages sometimes have those confusing indicators. At this point, I should probably assume any time a user interface element is especially bulky or confusing that it's copied from an Apple interface.

moritzwarhier

Just make the user more comfortable by adding a "Save" button! Genuine answer I got when I pointed out at a previous job that we were mixing immmediately effective toggles with other, non-immediately-effective inputs in the same form. The save button was meant to do nothing. I know, this article is about the toggle state (e.g. "Mute" or "Unmute"). But since toggles are more and more part of forms, I'm in for a rant about that. The no-op save-/done-button pattern has been established for a while now, see the "Done" button in this post. I think Apple started incorporating toggles into forms. But mixing both is truly evil. Apple is most times better in its own apps when it comes to that, because they make clear whenever a setting is "dirty", but they started all this. I don't remember which one it was, but recently I used a web or native app with settings forms, where the pages had a "save" button at the bottom and a "done" button at the top. "Done" would silently (!) discard your changes. In the situation I mentioned before, "Done" was meant to be a no-op for immediately effective controls and an "Apply" or "Save" for the ones that weren't. But as the world moves towards immediately effective controls, it should be really emphasized that the most important thing to me, as a user, is whether the form is in "auto-save" mode or not, and in almost all cases, the same paradigm should apply across the whole form.