Matt Gemmell

TOLL is available now!

An action-thriller novel — book 2 in the KESTREL series.

★★★★★ — Amazon

On/Off Switches

development, interface, software, source, tech, user experience & design 3 min read

Since iOS gave us a new type of checkbox control - the On/Off switch - I’ve noticed them appearing in more and more desktop applications too. Just today, I saw an example that displays terrible usability, and wanted to talk about it a little.

This example is from a piece of utility software that I use and enjoy, and I’m not going to name it since I want to talk about the user experience of the switch implementation itself, without needlessly fouling the specific utility. I hope that you’ll take a similarly classy approach if you post a comment.

Here’s a screenshot:

Putting aside the redundant and slightly confusing word “enable” in the label (it’s a horrible word, and it clouds the issue of whether something is actually on or just potentially on according to some other circumstance), this switch obviously controls whether a ‘history’ function is active or not. Here’s the question: would you say that, in the screenshot above, the switch is on or off?

To my eye, it’s currently on. There’s a silvery-grey switch set into a recessed trough, and you can move that switch from side to side to control its state. That’s how those switches work in the real world, and it’s what the appearance implies. And maybe it is on. Probably, even.

The problem is that both its appearance and interaction design confuse the issue.

The switch shows “On” and “Off” labels at the same time

Including both labels inside the switch boundary is the first step towards confusion, because you’re immediately making the user rely on a secondary cue to determine which one currently applies.

By contrast, here’s a standard iOS 5 switch in the On position:

And here’s one in the Off position:

There’s very little question as to what state these switches are in, because there’s only one state displayed - the current one. System-wide highlight colour is also used to considerable effect: when it’s on, it has energy; when it’s off, it doesn’t. Easy.

Another implementation is the one used by the first desktop example of a slider switch that I can remember seeing: the Time Machine pane in System Preferences on OS X. Here it is, in the On position:

This time, there’s no visual energy clue inside the switch itself, but the “ON” label does gain a dark green energy (Time Machine’s branding colour) when the switch is on, and reverts to grey when the switch is off. To reinforce the concept of energy meaning an active state, the “OFF” label remains grey at all times.

More importantly, the switch responds to click-toggling anywhere within its bounds or on its labels, the labels are set outside the switch so as to not clutter the switch display itself, and the switch knob can also be dragged as the appearance implies.

The switch can’t be toggled by clicking the inactive option

When the switch is on, you’d expect to be able to click on the ‘Off’ side to toggle it to off. This switch doesn’t work that way. Indeed, assuming that I understand its appearance above correctly (and that it’s thus currently on), you have to click the current state to toggle it to the opposite state! That’s crazy, to the point of surely just being a bug - no-one would actually design something to work that way.

By contrast, iOS switches can be tapped anywhere to toggle states.

The switch cannot be dragged between states

The entire visual design of this type of switch relies on us being familiar with physical toggle-switches in real life, thus we project an affordance of ‘toggleability’ onto this virtual switch.

Our brains understand that we can slide it between positions - indeed, there’s a big, inviting shadowed recess that we can clearly slide the switch towards, and we can see from how the light falls on the switch surface that it’s raised from the surrounding area, which will let our fingertips and nails get a hold of it. Furthermore, we probably expect the dragging to display a degree of ‘gravity’ or momentum, such that the switch will only flip states if it has been dragged at least halfway towards the new state.

Except that this switch can’t be dragged at all. Its actual ‘switch’ portion simply responds like a button, actually mirroring the inactive side if you click and hold on the active side.

It’s a train-wreck, and one that happens all too often when we allow our thinking to stop at “this new type of control looks cool, let’s make one like that”. We have to think about how and why particular interfaces work, rather than just mimicking their outward appearance.

For more thoughts on software interfaces and user experience, feel free to follow me (@mattgemmell) on Twitter.