GTK3 includes the new switch button. Sadly, at the time of this writing, there seems to be no HIG recommendation for it yet so I’m left to guess what its proper use should or shouldn’t be. I’m all for choice/flexibility for developers, but what has been worrying me slightly in the new Control Center is the possible abuse of this new widget. Currently, it’s all over the place.
This is not meant to pick on anyone, but I thought Bastien’s screenshot would illustrate my point:
“Well, what’s wrong with it”, you say? Let me answer with my GIMP’ed version of it:
I don’t know. Maybe I’m old (or too young) and I don’t get this fancy iOS-like thing, but I believe my version makes it much easier to understand and has better overall usability.
Here are the problems (or fundamental misunderstandings) I have with gtkswitch as it is currently used:
- It does not do anything different than a checkbox (or pushbutton) widget except that you can “slide” it… which, I guess, is aimed at mobile, touchscreen devices, right (with a computer, you can still click it like a “normal” checkbox anyway)? Which begs the question: even on mobile devices, how is sliding so much more easier than tap-clicking?
- If gtk’s checkbox doesn’t have a big enough target/sensitive area, just make it bigger so that I can hit it with my thumb finger.
- If you fear your users may accidentally tap the widget, that’s what screen locking is for.
- As illustrated in my mockup above, in most situations, a checkbox provides clearer meaning in two ways:
- You can actually write text in a coherent and unambiguous sentence around the widget
- The ON/OFF thing can be confusing to a minority of users: does the fact that it currently displays “ON” mean that it “is on” or that “clicking this will turn it on”?
- ON/OFF translates/localizes badly. I know, for one thing, that the French will never dare translate it. And even if they wanted to, it would never fit in such constrained space. Comparatively with hardware with laser-etched on/off switches, this is software, it can be expected to be translated.
So far, the only proper use case I can see for this widget is in extremely constrained spaces where you can’t fit more than one word.
What am I blatantly missing here? Please enlighten me.
Comments
49 responses to “On GtkSwitch2 min read”
I’m in agreement; the purpose of the GtkSwitch needs to be clearly explained because it’s rather sensitive to the context it is used in. Normal desktop menus aren’t good candicates.
Couldn’t agree more…
I agree that it needs to be clearly explained but there is a significant difference between a checkbox and a switch.
– A checkbox conveys the idea of an setting in the sense that it is not immediately obvious to the user that something is happening the moment you check it. In other words it feels as though it is just a setting to be queried at a later time when needed by the system
– A switch on the other hand conveys the idea of the current state of functionality and makes it obvious that changing the switch actually does something, ie the system actually changes behaviour to the indicated state.
So I would use a checkbox when I simply need a setting with immediate action, and switch when I actually want to act on the toggle immediately. In this sense a switch is closer to a togglebutton than a checkbox
That should have said:
So I would use a checkbox when I simply need a setting withOUT immediate action, and switch when I actually want to act on the toggle immediately. In this sense a switch is closer to a togglebutton than a checkbox
@Michel: I don’t know why users would expect nothing to happen with a CheckBox..
Many times in GNOME switching a CheckBox’s value changes the GConf value which in turn ‘pushes’ that settings to all corresponding entities.
Hi,
I also can’t agree more. I have really a lot of trouble to read / comprehend the state of the switch. This is probably due to not being used to it since I live in Germany.
I already had the exact same problem when I was living in the US for a year.
I just never was sure if a physical switch was on or of.
One of the reasons is probably that you don’t know how the switch would look in the other state. If I compare two switched next to each other, I automatically know which one is on, but if I only see one switch or both in the same state then I have no clue.
So please do not overuse this type of widget! Or better don’t use it at all until a designer has made a widget that is easier to comprehend.
About the comment on translating on/off, there is none, it’s on/off in English, and I/O for anyone else. https://bugzilla.gnome.org/show_bug.cgi?id=639794#c1
I couldn’t agree more with the blog post. When I first saw the switch button I thought it was a theme for the check button, and an ugly one. It might have its uses in some very specific cases in which turning a major feature, which affects a lot of other dependent features, on or off (Like the top left one in the example screenshot which toggles the whole Bluetooth feature). Other than that the check button with a text seems more explanatory and intuitive.
This was my experience with a lot of real life examples of such a button since their behaviour tend to differ from each other a lot. Some emphasize the behaviour by giving the current on state green light and off state red light, but this would be useless for people with color vision deficiency.
Actually I think the labels in the screenshot with switches contribute to it being hard to understand. On a physical machine it would say “Bluetooth” if that’s what it changes, not “Active”. I think the idea in principle is not bad, of using realistic controls, but then it has to be designed properly.
Yes, this is rather weird. Even Apple is not using those switches in OSX preference dialogs, apparently not even in the very iOS inspired Lion.
Also, what Markus said. “Active” is a really bad label for a switch to begin with. Either use the name of the system that is switched on, or none at all, if you think that it’s relation is obvious. “Active ON/OFF” really isn’t a far stretch from “On ON/OFF”.
Add one more to the count of people who find this control terrible. I cannot think of a single circumstance where this would improve on a checkbox.
One more in full agreement with you… I’m part of the “minority” who has trouble seeing whether “On” means that it _is_ on or that I should toggle the switch to turn it on — terrible. I can see that this widget might be useful in a “control panel” type of app, but for settings I also find the checkboxes more illustrative.
And translating on/off to 0/1 doesn’t really make things any clearer, either.
Completely agree. I’ve been worried about this since I’ve first seen it used in mockups, but had hoped I’d just be a theme for checkboxes and not an entirely new widget.
There’s no way that screenshot can actually be true, you must have misinterpreted something sir.
We all know GNOME development and design happens wild in the open with years of talks about design changes, so i guess you just picked some random user-generated (inkscaped) mockup.
My own impression is its meant to be used as a master ON/OFF switch for a large capability or a set of options. I’ve also seen it used to graphically represent a bank of dip switches (accessibility settings, for example). It’s visually appealing when used sparingly, but I agree the Control Center seems to be falling prey to the “hey neat widget, let’s use it everywhere!” mindset.
Yep. We should have updated the HIG first and then written a UI to match.
This way the UI’s a mess, and whoever gets round to writing a HIG will have fun trying to make sense of it. (As will users.)
Good point! filed a bug in the HIG > (https://bugzilla.gnome.org/show_bug.cgi?id=644657)
Let’s hope to fix this before we have windows running amok 😉
I couldn’t agree more too and i hope that this GtkSwitch will be used as less as possible
I cannot agree more. Count me to the minority of people who are constantly confused by these types of widgets never knowing whether the ‘ON’ means that it’s on or that clicking it turns it on (I have similar issues with some types of ‘mute’ “buttons” represented just by icon). IMHO both checkbox and togglebutton would work perfectly for this case (with checkbox offering more place for better wording of the action).
To me this widget seems like awfully implemented improvement to togglebutton that shows different text when in active state.
It’s simple. It’s there because the Designers want it.
I think the biggest problem with this is that it’s impossible to deduce it’s state.
Someone suggested used green/red color to assist, but that is exactly the same problem, just more of it.
Imagine this:
[on|off] Switch background to red
Or maybe this:
[on|off] Lock screen
(hint green signals open and red signals closed)
The control is broken. Really broken – and it improves nothing upon a standard checkbox.
I am a part of the (growing) minority of people is confused by this widget: does the fact that it currently displays “ON” mean that it “is on” or that “clicking this will turn it on”
Maybe, as Anders says, it would be better if there was some visual feedback like red/green.
I thought all three were off until I saw the checkbox version. I guess since I’ve never seen such slide switches in real life I have no experience to draw from.
The one exception is DIP switches, which I have seen – and which causes my confusion. DIP switches are “On” when the slide is on the same side as the “On” text, not the opposite one.
If the functionality is exactly the same as checkboxes, only worse, wouldn’t it be quite easy to do an automated search-replace in the source to replace them all downstream?
Couldn’t agree more. This appears to just be something someone thought was cool on their iPhone, then just copied into GTK – there’s no underlying rationale for it being there and it has no well defined role – hence there’s been no change in the HIG. As pointed out by everyone else, it’s considerably inferior to a checkbox, if it’s used in place of one.
I couldn’t agree more. Your mockup is MUCH easier to understand. Free software needs more people like you with such a sharp eye for usability.
How on earth did this widget get accepted into GTK+ in the first place?!
I’d have to disagree with you.
In my experience, check boxes are more confusing for user especially n00bs. Keeping a consistent interface and especially having one that has a real world analogue is a great way to communicate with the user.
If the text is ambiguous, no widget will change the confusion.
+1 your mockup is MUCH clearer.
IMO GtkSwitch should be used in very rare and special cases. Think fighter jet bombs-away switch.
I think it could make sense as a UI element representing a physical hardware switch. So in the case of toggling the power on a {monitor,wifi,bluetooth} device could be OK.
Couldn’t agree more…i never commented on the new switch button before, but apart from ‘it looks funky on the iPhone’, i yet need to be tought what it’s advantage over a checkbox is. Everything i’ve seen so far is bad UI. I admit that it’s a slightly more spacial control on touchscreens than a checkbox, but it trades that for an ambivalence in interpretation: Are the controls in the first screenshot set to on or off? Are they on because they read ‘on’ or are they off because the ‘slider’ is in the ‘off’ position. Without context or having seen a few of them you never know.
Hey,
Yes, we need to guidance on how to use the switch. A new version of the HIG is being planned, but it won’t be ready any time soon. In the mean time, we’ll hopefully have some interim guidance documentation.
Though the functional logic of a checkbox can be used instead of a switch, the latter have different semantics, and this makes the user interface more meaningful and therefore easier to understand.
The main thing that switches are useful for (instead of checkboxes) is for controlling services or hardware that have a clear on/off logic. They are particularly appropriate when those services or hardware do not activate immediately, or when they affect the operation of the system in a significant way.
Bluetooth is a good example of an appropriate use of a switch, therefore; visibility, less so (though you could still argue that it is OK in this situation).
Totally agree, the switch looks really out of place and it is hard to understand. I hope it goes away…
I totally agree with you
This will look even weirder then it’ll be translated to Lithuanian [On|Off] -> [Įjungta|Išjungta]
Then it will be “I / O” instead. Which even further stresses the point that this should be used for toggling system states, not as a generic replacement for checkboxes.
E.g.:
“Bluetooth ON/OFF” makes sense, and is more concise than “[x] Enable Bluetooth”.
“Repeat alarm daily ON/OFF” would look awkward though and not in any way superior to “[x] Repeat alarm daily”.
Another thing to keep in mind is visual clutter, especially when you start mixing and matching. Simple rules may not be enough in this case, but also require a designer’s eye. Whether the subtle different implications of the widget justify these complications remains to be seen I guess (at least on the desktop).
Clarity should not be an issue though, as long as the “ON” state is clearly highlighted (blue in this case), users will learn it very quickly. Colourblindness should not negate this either, as long as the difference is in value and not just hue.
I have to agree…
The (slide)-switch button (IMHO) is a over hyped fad from touch screen interfaces (Read: iOS and slide to power down, which is really only useful when you want to get a deliberate single action input from the user which must not suffer from accidental input). These controls do not necessarily have the same relevance in the traditional mouse/keyboard driven interface, and could be better implemented using the traditional check-box/toggle button options.
Off-hand this control leaves me with the same problem as the dual function pause/play single buttons found in media players… By just using visual output the user/I can not always determine if the control is showing the current state or that which will be changed when triggered. (Updating the HIG to ensure the user experience is always consistent would probably help).
Good example, Daniel. I’ve added it to some guidelines I’ve started throwing together:
http://live.gnome.org/Design/Whiteboards/SwitchGuidance
Hope that’s OK, and feel free to chip in.
I’ve NEVER seen “I/O” used on a real world switch that wasn’t placed on a power supply. And those I know if they’re on, not by looking at the switch, but through observing that which they supply with power. I doubt many people in Sweden has a different experience than me. Is this a common type of switch elsewhere? I’m not even 100% sure which of I and O represents on without thinking for a few seconds.
And it still has the problem of one not knowing the state of the button.
@Allan: I kinda agree about the “master switch that really toggles hardware on/off” such as Bluetooth on/off; but I believe the meaning of this widget gets diluted rapidly when used more than once or twice in a UI. Your guideline draft is a step in the right direction!
For example, in the UI above, the on/off switch could make some sense for the main Bluetooth switch, but be replaced by checkboxes for the visibility toggle and for the “enable this device” toggle…
You could argue that the “enable this device” option is less “bombs away” critical than disabling Bluetooth entirely.
I’m in 100% agreeathat GtkSwitch should be for hardware switches only.
In addition I’d like to suggest that the behaviour of the GtkSwitch perform a hardware on/off immediately (and not wait for the user to hit “apply” somewhere in the dialog).
Count me among the “minority” who have no idea what the state of the switch is – is it on now or do I need to slide it over the “on” label? The control as currently drawn is completely broken.
I don’t know; to begin with, Apple wasn’t the first person to integrate such a UI component, so more or less we’re just incorporating a new idea into the pool. The conflict that I see with this is probably with translations; but that can be fixed by omitting text and using graphical symbols and colors. My biggest opinion: GNOME needs to leave the 20th century and get ready for the 21st. Some people are afraid of change (I am, to an extent) but it’s needed if we’re going to prove again that *buntu and other systems are worthy opponents in the OS field.
Here is another GtkSwitch http://blogs.gnome.org/hughsie/2011/03/16/gnome-control-panel-network-status/
GtkSwitch:
worst. widget. ever.
But check boxes have a real world analogue, on “to do lists” or “shopping lists” made on paper people are used to check the items also every form you must fill out have check boxes for options.
Your conservative attitude towards change is bizarre. I’m sorry if I sound aggressive, but the only reason you think using checkboxes for ON/OFF functionality is because you’re used to it. Checkboxes should be used to make selections out of a list of entries. Which components would you like to install? Which emails do you want to delete?
It’s the same reason why you think your mockup is more intuitive. Because it looks exactly like what you’re used to.
Actually, having seen it in action (while trying to set-up blue-tooth in fedora 15), I found the real reason why I think this widget is badly executed: it does not look like active widget, more like a dynamic status icon, plus in ‘off’ state it looks like disabled widget. I would have never guessed I’m supposed to click that thingie to change the state. If it at least done something on-hoover, but nothing…
This is not how good widget is supposed to work.
OMG
Guys, I really don’t know how to use this widget. Without any context, I don’t know how to interpret it: is it on? Off?
It’s really confusing to me.
If it’s blue it’s on, if it’s grey it’s off.
But what about people who cannot distinguish colors? When using giant widgets you pretend to be careful about the people of limited possibilities. So it’s more look like typical hypocrisy than the real care. And I still find it to be over-obtrusive and hard to comprehend. It’s one of the basic widgets and it must be extremely clear and very intuitive to use, just like checkbox. I used this widget a couple of month already, but didn’t get into it and it’s unlikely I will. Guys, may be you like your designing decisions, but this thing is one of things that prevent any efficiency. Firs you managed to destroy gnome with gnome shell, second you are killing any possibility to return things back by introducing such a bizzare widgets. BTW, don’t notice my personal complaints: just think about color-blind persons who didn’t have any pissibility to use your stuff 😉