Switches vs Checkboxes in Xfce 4.14

[Steve Dodier-Lazaro]

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 :-)

Best,

  [0] https://developer.gnome.org/gtk3/stable/GtkSwitch.html
  [1] http://ux.stackexchange.com/questions/63884/checkbox-vs-toggle
  [2] https://www.google.com/design/spec/components/selection-controls.html



-- 
Steve Dodier-Lazaro
PhD Student
University College London
Free Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160503/fd415b9c/attachment.html>