https://community.kde.org/index.php?title=Plasma/RepeatedDiscussions/SwitchesVsCheckboxes&feed=atom&action=historyPlasma/RepeatedDiscussions/SwitchesVsCheckboxes - Revision history2024-03-29T14:42:52ZRevision history for this page on the wikiMediaWiki 1.40.2https://community.kde.org/index.php?title=Plasma/RepeatedDiscussions/SwitchesVsCheckboxes&diff=32901&oldid=prevUnormal: Added page about switches vs checkboxes2013-07-03T09:37:29Z<p>Added page about switches vs checkboxes</p>
<p><b>New page</b></p><div>From an [http://mail.kde.org/pipermail/plasma-devel/2013-May/025420.html email] of Thomas Pfeiffer:<br />
<br />
Well actually, there is an easy way to make it absolutely clear which is <br />
which, although it takes lots of horizontal space and probably looks very ugly <br />
if you have many switches in the same UI: Just add text labels on each side, <br />
next to the button, not inside of it. E.g. "OFF" or "O" on the left side, <br />
"ON" or "I" on the right side. That makes things perfectly clear.<br />
So if ambiguity is the only reason against using switches on Desktop, we <br />
should use them. If you can make it clear on a touch screen, you can make it <br />
clear on a normal monitor. However, there may be more reasons than that.<br />
<br />
Let us look at the issue more closely. First of all, switches are not merely <br />
the "touch version" of checkboxes. Some developers may use them that way, but <br />
they are not. They should be used for different purposes, and the GUI <br />
guidelines of systems that have both do make that clear (though interestingly, <br />
the decision criterion varies from platform to platform:<br />
<br />
- The Android design guidelines make the following distinction: "Checkboxes <br />
allow the user to select multiple options from a set. Avoid using a single <br />
checkbox to turn an option off or on. Instead, use an on/off switch."[1]<br />
<br />
- The guidelines for BB10 go in a similar direction[2]:<br />
"Use check boxes when users can select multiple items or options."<br />
"Use a toggle switch when users are choosing between two distinct options, <br />
such as Off and On. You can also use a toggle switch if you want to make a <br />
setting harder for users to change accidentally."<br />
<br />
So according to the Android or Blackberry guidelines, the Battery Monitor <br />
should use a switch, whereas the Printer Manager should use checkboxes. <br />
<br />
- The Meego UX guidelines[3] (yes, Meego is dead but that doesn't mean their <br />
guidelines are bad) say the following: "Toggle switches are best used in <br />
system or applications settings, and are best suited to toggle a setting or <br />
mode that affects the whole system. Good examples are switching<br />
networking or silent mode on or off." "A checkbox works in the same way as a<br />
toggle switch, but it is more suitable to use for smaller settings, like a <br />
preference in an application"<br />
<br />
So these guidelines would speak for using a switch in the Battery Monitor as <br />
well. Regarding the Printer Manager, it would be a question of interpretation.<br />
<br />
- The Windows Store apps guidelines[4] offer a distinction which I personally <br />
find the most logical: "Use a toggle switch for binary settings when changes <br />
become effective immediately after the user changes them." "Use a checkbox when <br />
the user has to perform extra steps for changes to be effective. For example, <br />
if the user must click a "submit" or "next" button to apply changes, use a <br />
check box."<br />
<br />
The reason why I find this logical is that it relates to the real-world <br />
equivalent of checkboxes and switches. When I flick a switch, usually something <br />
happens immediately. On the other hand, checking a box on a paper form does <br />
not immediately change anything, it only has an effect after I submitted the <br />
form somewhere. And this is similar in the digital world: Checkboxes first <br />
appeared on digital forms, where changes only went into effect after the form <br />
was submitted. Therefore if we only use checkboxes for changes without <br />
immediate effect, users can be sure that changing the state of a checkbox won't <br />
do any immediate harm.<br />
<br />
According to these guidelines, both Battery Monitor and Printer Manager would <br />
use switches.<br />
<br />
So conceptually there is indeed a difference between a checkbox and a switch. <br />
Now, with that said, comes the big "but":<br />
All of these guidelines are for touch-based OSes. Looking at the guidelines <br />
for mouse/keyboard systems from the same vendors reveals a different picture.<br />
<br />
Neither the OS X Human Interface Guidelines[5], nor the GNOME Human Interface <br />
Guidelines[6] (Toggle Buttons are not the same as switches!), the Microsoft <br />
guidelines for desktop applications[7] or the ChomiumOS guidelines[8] contain <br />
any mention of switches. They all have only check boxes.<br />
<br />
So why is that so, even though the criteria for using switches instead of <br />
checkboxes would apply in the desktop world as well? Unless someone here knows <br />
someone in the respective teams at these companies or digs up a blog post <br />
explaining the decision not to introduce switches in the desktop world, we can <br />
only speculate.<br />
One reason is surely that flicking a switch on a touch screen, though not <br />
"natural" at all because of the lack of haptical feedback, is much closer to <br />
reality than flicking a switch by clicking it with a mouse.<br />
Another reason is surely that accidentally clicking a checkbox with a mouse is <br />
much less likely than accidentally tapping it on a touch screen (which the <br />
BB10 guidelines mention as one argument for using a switch and which is also <br />
underlying the guideline from Microsoft).<br />
<br />
Sure, Metro apps would display switches on the Desktop as well, and so does <br />
GNOME 3, but that's only because they're trying the "One size fits all" <br />
approach, which Plasma explicitly does not adopt (and if we look at the <br />
"success" of Windows 8 so far, I think that's a good decision). In their <br />
guidelines specific for desktop applications, both do not mention switches.<br />
<br />
[snip]<br />
<br />
So, to summarize: The industry has mostly adopted a distinction between <br />
checkboxes and switches in the mobile world, but sticks with checkboxes only <br />
in the desktop world and I see no compelling reason for being the only <br />
environment that has switches in desktop-only UIs.<br />
<br />
And If a developer works around the standard to display switches in his or her <br />
desktop UI, that UI should not become part of Plasma Desktop, unless we agree <br />
that we want switches in general (for a reason yet to be brought forth).<br />
<br />
<br />
* [1] http://developer.android.com/design/building-blocks/switches.html<br />
* [2] http://developer.blackberry.com/devzone/design/bb10/components.html<br />
* [3] https://meego.com/sites/all/files/users/admin/meego_touch_ui_v1.2.pdf<br />
* [4] http://msdn.microsoft.com/en-us/library/windows/apps/hh465475.aspx<br />
* [5] http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Controls/Controls.html<br />
* [6] https://developer.gnome.org/hig-book/stable/controls.html.en<br />
* [7] http://msdn.microsoft.com/en-us/library/windows/desktop/aa511482.aspx<br />
* [8] http://www.chromium.org/chromium-os/user-experience/ui-elements</div>Unormal