Switches vs Checkboxes in Xfce 4.14

Mon May 16 08:32:59 CEST 2016

On Tue, May 3, 2016 at 3:53 PM, Matthew Brush <mbrush at codebrainz.ca> wrote:
> 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.
>
+1

Whenever I find myself confronted with switches (either on mobile
devices or on desktop), I can't seem to figure out (1) whether the
thing is on/off and (2) how the user is supposed to turn the thing
off/on. When this happens I tend to hit or drag the thing randomly
(with finger or mouse) to see how the state changes (as well as things
around it) to decide if I've just turned it off or on... Confusing UI
if you asked me, but maybe I'm just a minority.

I do agree though that switches could be appropriate for turning
on/off entire components, like e.g. Compositor, whereas when "off" the
remaining of the dialog for that component is greyed-out (thus clearly
indicating the user what the state of the switch currently is).

My 2 cents,
Liviu

PS Here are two questions on UX StackExchange that discuss precisely
these issues:
http://ux.stackexchange.com/questions/63884/checkbox-vs-toggle
http://ux.stackexchange.com/questions/1318/should-a-toggle-button-show-its-current-state-or-the-state-to-which-it-will-chan

Bottom line is that switches can come with significant usability
issues (both in real-life physical switches---I for one never know in
my house whether the electrical switches are on or off which is a
dangerous UX standard if you asked me---and digital equivalent ones).
And checkboxes are generally easier to interpret instantaneously.

> 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
>
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev

-- 
Do you think you know what math is?
http://www.ideasroadshow.com/issues/ian-stewart-2013-08-02
Or what it means to be intelligent?
http://www.ideasroadshow.com/issues/john-duncan-2013-08-30
Think again:
http://www.ideasroadshow.com/library