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.
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.
That’s a good point. We associate the classic UI controls with forms that are submitted by another action. Autosaving controls have a slightly different function and feel.
> We associate the classic UI controls with forms that are submitted by another action.
Maybe some people do, but not everyone, and certainly not always since the toggle button UI is relatively new. The question to ask would be whether that association is good or bad, necessary or unnecessary, and whether the association can just be changed by removing them and letting people get used to the old way again.
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.
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.
> 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.
Graphite is one of the official standard configuration settings.
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.
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.
That’s a good point. We associate the classic UI controls with forms that are submitted by another action. Autosaving controls have a slightly different function and feel.
> We associate the classic UI controls with forms that are submitted by another action.
Maybe some people do, but not everyone, and certainly not always since the toggle button UI is relatively new. The question to ask would be whether that association is good or bad, necessary or unnecessary, and whether the association can just be changed by removing them and letting people get used to the old way again.
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.
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.
> 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.
Graphite is one of the official standard configuration settings.
One of eight color choices. Last one in the list.
If anything, the argument works better as a reason to remove gray from the list.