<div dir="ltr">Hi everyone,<br><br>It's come to my attention that there's now a thing called GtkSwitch, that seems to serve the same purpose as GtkCheckboxButton. It might be tempting to just go with the "new" thingy, so I'd like to bring in some knowledge from ergonomics in order for us to properly decide when we are using switches and when we are using checkboxes.<br><br><br>CHECKBOXES come from the world of paper forms. Most adults will have, at some point, been asked to fill paper forms where they indicate choice. There are several visual representations of choice, including ticking a box, crossing a box, filling up a box, circling a selected item, or barring unwanted items. The crossing a box action has caused some trauma, as in specific cultures the act of crossing means that an item is unwanted. Therefore, we're left with 4 different representations that we can assume are culturally universal.<br><br>Checkboxes are relatively small in size, so they can work inline with text without breaking the layout of the text, provided the spacing between the box and its label is relatively small. They are also commonly found in paper forms where it is usually expected that the nearest text label applies to the box.<br><br><br>SWITCHES come from physical switches on appliances like kettles or plugs. They perform the function of turning things on and off. Sometimes, a switch contains an indication of its current state (red tag on the ON side of UK plugs, ON or OFF label). However, the state indicator is always ambiguous, as users have to think whether it indicates the current state, or the state triggered by the current affordance of the switch (state-action ambiguity, see [1]). Therefore, it's very common for a duplicate indicator to be present, so users can decide whether the appliance is active or inactive. On light plugs, the bulb itself will play this role. On kettles and electronic appliances, a LED is usually present that indicates whether current is passing through or not.<br><br>Therefore switches are used for making things active or inactive, and particularly match the concept of enabling a service or activating a mode on a computer system. It's also good to ensure that the user gets separate, immediate visual feedback whether the switch is in an ON or OFF state.<br><br><br>Now onto why I think GtkSwitches have the potential to be a usability disaster. There are potential design issues with GtkSwitches which depend on the user's theme:<br><br>- the reference decoration of GtkSwitch is that a button knob covers the unselected state [0]. This can conflict with the interpretation of circling or filling up the desired selection in a form.<br>- the additional status indicator is a colour. The item is coloured when on and grey when off. Alas, both Android and GTK+ also use colours to indicate a recommended value or a recommended action when multiple buttons are available. There is hence still some cognitive dissonance for users to decide whether this means "the switch is on", or "the switch is off but it's recommended to turn it on".<br>- some themes use the I and O technical symbols rather than ON/OFF labels, which is confusing. Not everyone has training in electricity. We should not assume lay people know or remember the labels.<br><br>Most of these issues will disappear once users learn, from fiddling and making mistakes, the meaning of the widgets. The learning will occur easily is immediate external feedback is available for users to understand if something is on. For instance:<br><br>" [ON]/[OFF] WiFi" -> I can tell whether or not the network applet is spinning afterwards because it's connecting onto my local WiFi network<br><br>" [ON]/[OFF] Enable a specific behaviour when an uncommon event occurs in the future" -> I have to wait and see, and suffer the consequences of a potential mistake while still in the learning phase<br><br>Most of the "Enable ..." checkboxes we have in our settings are going to describe behaviours in response to events, so switches will not be appropriate from a semantics standpoint.<br><br>From a graphic design standpoint, putting multiple switches next to one another breaks the layout of the form. It causes people's brains to form different visual groupings: a vertical group of switches, and a vertical group of labels. This increases the cognitive cost of associating labels to switches. Because checkboxes are smaller than a line of text, there is higher vertical spacing between boxes and they compete less with an horizontal grouping of the UI elements.<br><br>The settings UIs of Xfce are not control panels for groups of kettles. They're forms, so it's better to stick to the form vocabulary and layout. The Google Material guideline recommends using switches for a single binary state toggle, and checkboxes for groups of toggles [2]. I propose we stick with that interpretation and keep checkboxes everywhere in the settings UIs.<br><br>We can then decide case by case where to use switches. The Accessibility settings dialog is a good example of where we might want switches. Turning the switch on for the Mouse Emulation will immediately enable multiple other options, and there is a state involved (emulation enabled or disabled), so the switch fits. If people want to start switching to switches (!) right now, of course I'm happy to give my lazy-ass-who-didnt-submit-patches-for-ages opinion on whether it's suitable or not :-)<br><br>Best,<br><br>  [0] <a href="https://developer.gnome.org/gtk3/stable/GtkSwitch.html">https://developer.gnome.org/gtk3/stable/GtkSwitch.html</a><br>  [1] <a href="http://ux.stackexchange.com/questions/63884/checkbox-vs-toggle">http://ux.stackexchange.com/questions/63884/checkbox-vs-toggle</a><br>  [2] <a href="https://www.google.com/design/spec/components/selection-controls.html">https://www.google.com/design/spec/components/selection-controls.html</a><br><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Steve Dodier-Lazaro<br>PhD Student<br>University College London<br>Free Software Developer<br></div></div></div>
</div>