Image by: Nuno Pinheiro Following posts on specific work being done on Oxygen, this post is going to try to go beyond the manifest work and look at the bigger picture driving it. The motivation for…
Real checkboxes can also take effect immediately, and have much better visual cues. The submit button was intended to save older computers the extra monitoring load of having to keep track of the state of every control all the time—it has nothing to do with control styling.
I mean, they can, and they can also be made to be mutually exclusive - but it’s better to use radio buttons in that case. If that pattern is used, there’s not really a good way that a checkbox will take effect immediately beforehand, or whether it will require submitting a form, except scanning the full page to look for such a button.
Eh? What do radio buttons have to do with anything?
The styling of a UI element - whether it’s a box that gets an X or tick in it, versus a little thingy that moves left and right - is wholly unrelated to any aspects of implementation, including whether the effect happens immediately or not.
I was trying to make the point that the way a control looks gives you some information on how it will behave, because software has generally been consistent with associating those looks with those behaviours.
So if you see multiple options with a circle in front of them, selecting one, then selecting another will usually deselect the first one.
On the other hand, if those options have squares in front of them, selecting one, then selecting another will usually result in both of them being selected.
And in both cases, usually they will be part of a form and will only take effect when you submit that form using a button.
On the other hand, something that looks like a toggle usually takes effect immediately on toggling.
Of course it is technically always possible to have each of those behave like any of the others, but you will be breaking conventions if you do so. Styling is an affordance to inform the user about the behaviour.
Taking effect instantly is not really indicated by the control shape; it’s indicated by whether or not the form has a button equivalent to “apply”. Settings pages with checkboxes that applied immediately have been common for years; this distinction is not nearly as clear cut as you make out. I suspect what is going on is that both toggle switches and the removal of a separate apply step has gone on gradually at the same time.
But a good thing to think about is all the other controls: drop downs, text entry boxes, date pickers - these have no second version which might apply instantly or not! So it’s a mistake to think that information is conveyed by the look of the control.
Well, I’d encourage you to keep an eye out; I think you’ll find that the majority of controls on the web behave as I described. And I think that’s a good thing, too: it’s far quicker and easier to be able to deduce behaviour from the control you’re handling at the moment, than having to scan the complete context. And especially if e.g. you’re visually impaired, the latter can be a major hassle.
(And indeed, the other controls you mention almost never apply instantly, so their behaviour is still predictable. When they do, they’ll often still have some other affordances to indicate that they do apply instantly.)
GNOME settings pages don’t have “apply” buttons. When do you think a selection from a drop-down or numerical selector takes effect?
Yes, most settings now take effect immediately, and that’s great. (I think KDE still prefers a separate “apply” step though). That is (still) separate from the decision of how to style something which turns something on and off, which is what I’m complaining about. I don’t take any issue with having things apply immediately.
You raise visual impairment, which is exactly why I’m complaining. Look at the image and tell me, which of the controls is on, and which is off?
True, there are exceptions (that’s why I keep saying most), and I think the pattern is more common on web than on desktop. (Though I think Gnome also compensates a bit with their boxed lists as an additional affordance.)
Note that I am 100% on your side in saying that there are annoying toggle boxes that are unclear. In your image, I can only tell that the second is probably on because the right-hand side is usually used for the on state in LTR locales. But they can be better, e.g. with an on/off label integrated. Ironically, GNOME has a toggle to enable this:
So (unsurprisingly) I modified the image to make my point. I don’t know whether you will find it convincing with this revealed: I flipped the image because I too understand now (I did not when these switches were first introduced) that right = on. And I also desaturated the image to mimic colourblindness (achromatopsia). (Indeed, when they were first introduced I remember them being two shades of grey…)
Real checkboxes can also take effect immediately, and have much better visual cues. The submit button was intended to save older computers the extra monitoring load of having to keep track of the state of every control all the time—it has nothing to do with control styling.
I mean, they can, and they can also be made to be mutually exclusive - but it’s better to use radio buttons in that case. If that pattern is used, there’s not really a good way that a checkbox will take effect immediately beforehand, or whether it will require submitting a form, except scanning the full page to look for such a button.
Eh? What do radio buttons have to do with anything?
The styling of a UI element - whether it’s a box that gets an X or tick in it, versus a little thingy that moves left and right - is wholly unrelated to any aspects of implementation, including whether the effect happens immediately or not.
I was trying to make the point that the way a control looks gives you some information on how it will behave, because software has generally been consistent with associating those looks with those behaviours.
So if you see multiple options with a circle in front of them, selecting one, then selecting another will usually deselect the first one.
On the other hand, if those options have squares in front of them, selecting one, then selecting another will usually result in both of them being selected.
And in both cases, usually they will be part of a form and will only take effect when you submit that form using a button.
On the other hand, something that looks like a toggle usually takes effect immediately on toggling.
Of course it is technically always possible to have each of those behave like any of the others, but you will be breaking conventions if you do so. Styling is an affordance to inform the user about the behaviour.
Taking effect instantly is not really indicated by the control shape; it’s indicated by whether or not the form has a button equivalent to “apply”. Settings pages with checkboxes that applied immediately have been common for years; this distinction is not nearly as clear cut as you make out. I suspect what is going on is that both toggle switches and the removal of a separate apply step has gone on gradually at the same time.
But a good thing to think about is all the other controls: drop downs, text entry boxes, date pickers - these have no second version which might apply instantly or not! So it’s a mistake to think that information is conveyed by the look of the control.
Well, I’d encourage you to keep an eye out; I think you’ll find that the majority of controls on the web behave as I described. And I think that’s a good thing, too: it’s far quicker and easier to be able to deduce behaviour from the control you’re handling at the moment, than having to scan the complete context. And especially if e.g. you’re visually impaired, the latter can be a major hassle.
(And indeed, the other controls you mention almost never apply instantly, so their behaviour is still predictable. When they do, they’ll often still have some other affordances to indicate that they do apply instantly.)
GNOME settings pages don’t have “apply” buttons. When do you think a selection from a drop-down or numerical selector takes effect?
Yes, most settings now take effect immediately, and that’s great. (I think KDE still prefers a separate “apply” step though). That is (still) separate from the decision of how to style something which turns something on and off, which is what I’m complaining about. I don’t take any issue with having things apply immediately.
You raise visual impairment, which is exactly why I’m complaining. Look at the image and tell me, which of the controls is on, and which is off?
True, there are exceptions (that’s why I keep saying most), and I think the pattern is more common on web than on desktop. (Though I think Gnome also compensates a bit with their boxed lists as an additional affordance.)
Note that I am 100% on your side in saying that there are annoying toggle boxes that are unclear. In your image, I can only tell that the second is probably on because the right-hand side is usually used for the on state in LTR locales. But they can be better, e.g. with an on/off label integrated. Ironically, GNOME has a toggle to enable this:
So (unsurprisingly) I modified the image to make my point. I don’t know whether you will find it convincing with this revealed: I flipped the image because I too understand now (I did not when these switches were first introduced) that right = on. And I also desaturated the image to mimic colourblindness (achromatopsia). (Indeed, when they were first introduced I remember them being two shades of grey…)