Switches vs Checkboxes in Xfce 4.14

[Matthew Brush]

On 2016-05-03 05:46 AM, Steve Dodier-Lazaro wrote:
> Hi everyone,
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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.
>
> 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.
>
>
> 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:
>
> - 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.
> - 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".
> - 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.
>
> 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:
>
> " [ON]/[OFF] WiFi" -> I can tell whether or not the network applet is
> spinning afterwards because it's connecting onto my local WiFi network
>
> " [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
>
> 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.
>
>  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.
>
> 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.
>
> 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 :-)
>

As a user, thank you for articulating the problems of the switch widget 
so clearly.

Another thing you didn't mention is that on a non-touch-screen device, 
it's unclear how to actually activate the switch. On a touchscreen, it 
operates like its real life counterpart somewhat, you slide it left or 
right (or up or down) and the massive size allows for fat fingers to hit 
it. With the mouse it's awkward using slider-like mouse drag for a 
binary widget. Some GUI switches let you click at either end to turn it 
on or off (assuming you can figure out which is which) while some let 
you click anywhere to toggle it, but that basically breaks the metaphor 
and takes away the one good thing about GUI switches. It's also 
confusing with the keyboard, determining whether it's the Space key to 
toggle or left/right arrows to slide it on/off (or both?).

My personal opinion is that the switch widget should be restricted to 
applications tailored specifically for touch screens (point of sale, 
kiosk, etc), not for common mouse/keyboard driven desktop apps.

Cheers,
Matthew Brush