Switches around the world and broken metaphors [Was: Battery Monitor revamp]

[Thomas Pfeiffer]

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."[1]

- The guidelines for BB10 go in a similar direction[2]:
"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[3] (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[4] 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 
check box."

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 
use switches.

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[5], nor the GNOME Human Interface 
Guidelines[6] (Toggle Buttons are not the same as switches!), the Microsoft 
guidelines for desktop applications[7] or the ChomiumOS guidelines[8] 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 
only speculate.
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.
Cheers,
Thomas


[1] http://developer.android.com/design/building-blocks/switches.html
[2] http://developer.blackberry.com/devzone/design/bb10/components.html
[3] https://meego.com/sites/all/files/users/admin/meego_touch_ui_v1.2.pdf
[4] http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx
[5] 
http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html
[6] https://developer.gnome.org/hig-book/stable/controls.html.en
[7] http://msdn.microsoft.com/en-us/library/windows/desktop/aa511482.aspx
[8] http://www.chromium.org/chromium-os/user-experience/ui-elements