Switches around the world and broken metaphors [Was: Battery Monitor revamp]
colomar at autistici.org
Sun May 26 16:07:14 UTC 2013
On Sunday 26 May 2013 00:05:56 Marco Martin wrote:
> On Saturday 25 May 2013 14:32:29 Martin Graesslin wrote:
> > > And this is clearly the case let's work around something we don't want
> > > to
> > > fix. Switches are a clear improvement over checkboxes depending on the
> > > context even my 60yo mom got it much quickier than a checkbox would be
> > > able
> > > to on my plasmoids.
> > And I would completely fail to use the switch. I have huge problems
> > understanding those switches and I have not seen any implementation of the
> > switch where I got which one is on and which one is off.
> that's for me as well.
> I have to spend a second or more every time to figure/remember if the "on"
> that is written on the switch (or being colored vs greyed, same thing) means
> "it's on now" or "it's an action, so it's telling me it becomes on if i
> click on it"
Well actually, there is an easy way to make it absolutely clear which is
which, although it takes lots of horizontal space and probably looks very ugly
if you have many switches in the same UI: Just add text labels on each side,
_next to_ the button, not inside of it. E.g. "OFF" or "O" on the left side,
"ON" or "I" on the right side. That makes things perfectly clear.
So if ambiguity is the only reason against using switches on Desktop, we
should use them. If you can make it clear on a touch screen, you can make it
clear on a normal monitor. However, there may be more reasons than that.
Let us look at the issue more closely. First of all, switches are _not_ merely
the "touch version" of checkboxes. Some developers may use them that way, but
they are not. They should be used for different purposes, and the GUI
guidelines of systems that have both do make that clear (though interestingly,
the decision criterion varies from platform to platform:
- The Android design guidelines make the following distinction: "Checkboxes
allow the user to select multiple options from a set. Avoid using a single
checkbox to turn an option off or on. Instead, use an on/off switch."
- The guidelines for BB10 go in a similar direction:
"Use check boxes when users can select multiple items or options."
"Use a toggle switch when users are choosing between two distinct options,
such as Off and On. You can also use a toggle switch if you want to make a
setting harder for users to change accidentally."
So according to the Android or Blackberry guidelines, the Battery Monitor
should use a switch, whereas the Printer Manager should use checkboxes.
- The Meego UX guidelines (yes, Meego is dead but that doesn't mean their
guidelines are bad) say the following: "Toggle switches are best used in
system or applications settings, and are best suited to toggle a setting or
mode that affects the whole system. Good examples are switching
networking or silent mode on or off." "A checkbox works in the same way as a
toggle switch, but it is more suitable to use for smaller settings, like a
preference in an application"
So these guidelines would speak for using a switch in the Battery Monitor as
well. Regarding the Printer Manager, it would be a question of interpretation.
- The Windows Store apps guidelines offer a distinction which I personally
find the most logical: "Use a toggle switch for binary settings when changes
become effective immediately after the user changes them." "Use a checkbox when
the user has to perform extra steps for changes to be effective. For example,
if the user must click a "submit" or "next" button to apply changes, use a
The reason why I find this logical is that it relates to the real-world
equivalent of checkboxes and switches. When I flick a switch, usually something
happens immediately. On the other hand, checking a box on a paper form does
not immediately change anything, it only has an effect after I _submitted_ the
form somewhere. And this is similar in the digital world: Checkboxes first
appeared on digital forms, where changes only went into effect after the form
was submitted. Therefore if we only use checkboxes for changes without
immediate effect, users can be sure that changing the state of a checkbox won't
do any immediate harm.
According to these guidelines, both Battery Monitor and Printer Manager would
So conceptually there is indeed a difference between a checkbox and a switch.
Now, with that said, comes the big "but":
All of these guidelines are for touch-based OSes. Looking at the guidelines
for mouse/keyboard systems from the same vendors reveals a different picture.
Neither the OS X Human Interface Guidelines, nor the GNOME Human Interface
Guidelines (Toggle Buttons are not the same as switches!), the Microsoft
guidelines for desktop applications or the ChomiumOS guidelines contain
any mention of switches. They all have only check boxes.
So why is that so, even though the criteria for using switches instead of
checkboxes would apply in the desktop world as well? Unless someone here knows
someone in the respective teams at these companies or digs up a blog post
explaining the decision not to introduce switches in the desktop world, we can
One reason is surely that flicking a switch on a touch screen, though not
"natural" at all because of the lack of haptical feedback, is much closer to
reality than flicking a switch by clicking it with a mouse.
Another reason is surely that accidentally clicking a checkbox with a mouse is
much less likely than accidentally tapping it on a touch screen (which the
BB10 guidelines mention as one argument for using a switch and which is also
underlying the guideline from Microsoft).
Sure, Metro apps would display switches on the Desktop as well, and so does
GNOME 3, but that's only because they're trying the "One size fits all"
approach, which Plasma explicitly does _not_ adopt (and if we look at the
"success" of Windows 8 so far, I think that's a good decision). In their
guidelines specific for desktop applications, both do not mention switches.
> to me that slowing down is consistent, and that's what makes a broken
> paradigm. maybe is not like that for everybody (it may indeed depend from
> power switches in europe looking completely different).
> but i would like to see a real user test statistic prior to reevaluating
> them in any way.
> on touch they became so universal that's probably fine (and interacting with
> it with touch is a bit more natural)
I've read from a few users in the PA community on G+ that they don't
understand the current switch in PA either and I think it could still be
improved even for touch devices.
> on the desktop they should really never be there (btw, in 4.11 on the
> desktop switch will look exactly like a checkbox)
> and last, the use of one or another should not depend from the choice in the
> application, we have too many inconsistencies already without introducing
> new ones
So, to summarize: The industry has mostly adopted a distinction between
checkboxes and switches in the mobile world, but sticks with checkboxes only
in the desktop world and I see no compelling reason for being the only
environment that has switches in desktop-only UIs.
And If a developer works around the standard to display switches in his or her
desktop UI, that UI should not become part of Plasma Desktop, unless we agree
that we want switches in general (for a reason yet to be brought forth).
I hope this input helps taking the whole discussion to a more factual level.
More information about the Plasma-devel