Toggles Considered Harmful
52 points by wezm
52 points by wezm
There is an accessibility setting on macOS named "differentiate without color", which does help by showing little on/off indicators on the toggles. I would go so far as to say it should be the default.
On iOS that switch is named "On/Off Labels".
Ironically, enabling the setting "Differentiate Without Color" appears to do nothing to the toggles themselves. The only place I have noticed is an added icon to overdue reminders. For example, an unfinished reminder that was set for yesterday has a red label, "yesterday". With "Differentiate Without Color" enabled, that same label is now preceded with a small calendar icon, also in red. I did not find other cases where that setting would make a meaningful difference.
I can't comment on the most recent macOS, but it seems like iOS has two settings - labels, and differentiate without colour, while macOS has just differentiate without colour - but it does what both options do on iOS.
Ah, thank you for sharing! I'm surprised by how subtle the stylistic difference is while still being much clearer. I agree, it would be a better default.
In the earlier days, it was very clearly established that toggles were for things that had immediate visible effect (rather than taking effect when you submit the form), and you should otherwise use checkboxes. This is probably an abuse of toggles in this dimension.
Things have got a bit less clear as more things do take immediate effect and form submission is less commonly required.
Also it’s a bad panel, covering two completely unrelated things. The first thing is in altogether the wrong place.
(I don’t know what the entire thing looks like, but https://support.apple.com/en-in/guide/mac-help/mh40768/mac describes it in writing.)
Another couple of problems here are the stupid accent colour (“graphite” shouldn’t even be an option) and that it’s too wide—toggles work fine on phones, but if you let it get larger, the right-anchoring of the toggle takes it too far from its text.
In the earlier days, it was very clearly established that toggles were for things that had immediate visible effect
I've heard this before, but was it ever anything other than convention? Did the average non-developer know this? It seems like such an arbitrary thing that would have had to been explained in user manual or something, and I think we both know how many people read the documentation.
I heard it said and instructed quite frequently early on. I think it was a part of Apple’s Human Interface Guidelines at the time. But now https://developer.apple.com/design/human-interface-guidelines/toggles offers little guidance on the topic.
I've never heard of it. On Mac OS X checkboxes had immediate effect wherever possible. It actively avoided Windows' design of Apply button.
iOS was never quite the same as macOS in such things. Early on, switch toggles were specifically a mobile thing. Not sure how recently they started using them in macOS, but it can’t be that long ago, I imagine. Within Apple’s design system, switch toggles never really worked well on desktop, and still don’t.
I agree, but there are two things one should add here.
Almost all forms only use checkboxes with an "apply" button. It might be unexpected that merely checking or unchecking a checkbox has immediate side-effects. Be aware of that.
There is another reason why toggles are flawed UI elements. Suppose you click a toggle switch and enable it. Then, visually, that switch moves immediately. But if behind the scenes, this setting is actually controlled by a remote service and a network request has to be dispatched, the feature is not yet turned off until the target system has received that request. Hence, the switch prematurely signals success. In case you get an error response when applying the setting, you have to bounce back the toggle switch, which is very jarring and often unexpected. The conclusion to draw is that toggles are the wrong UI element for settings that can either take a long time to apply or can fail. This includes things like WiFi and Bluetooth toggles, which often require lengthy driver negotiations to change state. You often see interfaces that struggle to display these states properly, precisely because they have chosen the wrong UI elements that now fight against the underlying information, rather than presenting it properly.
That's a Windows design. Apple never had an "Apply" button.
macOS had "indeterminate" checkbox state for this. Apple is regressing in UI design quality.
In Android world, some of them requires swiping and some of them requires tapping. With checkbox, you always know the deal.