GNOME Bugzilla – Bug 644658
GtkSwitch labels are misleading
Last modified: 2018-05-02 15:04:14 UTC
I've noticed I always understand the on/off switches the bad way, and it's because the on/off labels are drawn within the switch. The issue lies in the very fact that there is two way to interpret something such as this: [ On [XX]] Would it be "If I click on it it will be on", or "it is on, I can click on it and turn it off" ? Looking around, I noticed most hardware have switches presented this way: On [ [XX]] Off In this way, it's explicit that the right value for the switch is the label on the left, because the switch itself is on the left. The reason the small switch is misleading is because it's actually *not* a compact version of the above, but behaves in the exact opposite way. I think the switch should be reworked to look more alike hardware switches, and draw the labels outside, so we'd have this: Sound: On [[XX] ] Off instead of Sounds: [ On [XX]]
I think such a slidy switch can be seen as an improvement over check boxes. Since check boxes are from pen and paper forms which could be confusing to have along with button, sliders and other mechanical physical inspired widgets. If the goal is to ensure greater consistency and physical metaphors, then buttons with an embedded status light might be a better choice - at least for non-touch-screen interfaces. People will soon enough learn what these toggle-switches do if they continue showing up in GUIs, but they are big, clunky and seem to cause at least initial confusion.
I agree with the reporter, and there have already been many reports about this being confusing. Here's a mockup did a while ago, that resembles the proposed fix: http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/web-services/web-services.png It's much clearer. It also has the advantage that it can be localised easier, and the states on either sides can also be changed to other thing. For example 24h/12h clock for the contol centre's time panel, and photo/video camera mode for Cheese etc. Hopefully this will be considered. I will make some better visual style for Adwaita if people agree this is the route to go on.
To quote Patryk Zawadzki from buf 639794: > Not sure about labels but switches in Europe hardly ever look like that widget. > We either use flip switches where both labels are always visible or slide > switches with labels surrounding the widget itself: > > 1 [<> ] 0 > I [<> ] O > ON [<> ] OFF > > The only switch I could find that resembled the current widget GTK and shell > use was the voltage switch on the back of my office PC. With a little twist > that the labels were physically attached to the moving part so when you slid > it, it did not cover the other label, but pushed it out of the view instead. > > Isn't there a better way to represent the switches for the wider audience?
In fact, I think no label would be less misleading than the labels inside of the switch.
(In reply to comment #2) > Here's a mockup did a while ago, that resembles the proposed fix: > http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/control%20center/web-services/web-services.png > > It's much clearer. It also has the advantage that it can be localised easier, > and the states on either sides can also be changed to other thing. For example > 24h/12h clock for the contol centre's time panel, and photo/video camera mode > for Cheese etc. This is a very good point! I like the idea of having the text outside the button and let the app set its own labels.
Made a mockup: http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/theming/switches.png
(In reply to comment #6) > Made a mockup: > http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/theming/switches.png Oh dear lordee NO! :s That is overdoing what could be done with a togglebutton as requested on Bug 611695 , especially the 2nd and 3rd. A better option for those would be the togglebutton > http://people.gnome.org/~fargiolas/toggle-button-mockup.png . If the GTKSwitch is used for anything than just ON/OFF it makes little sense to even have this switch. It's better just do the ToggleButton even for ON/OFF where we could just embed an ON/OFF image on the buttons..
Created attachment 183665 [details] GTK Switch Mockup How I see the current GTK Switch is that it looks like the IN/OUT boards <http://www.office365.co.uk/im/pim/327050.jpg> or the iP*d Lock switches and I've also see it on a few electronic switches, where the state is written on the inside which gets exposed on pushing the knob to the side. However this works since the knob is the only interaction, and pushing the knob to the other side reveals the state. This works well in touch interfaces too.. But we seem to be confused here because the state can also be changed by clicking on the ON/OFF part. What we could do for the GTK Switch is to turn the knob into the state indicator. IMO, it could work without labels too. If someone is not familiar with this kind of a switch, they could quickly realize that one side is ON(knob color) and the other side is OFF. Seems like a better option than the I/O we use for the non-english locales.
*** Bug 649405 has been marked as a duplicate of this bug. ***
Since it was mentioned in the duplicate bug but not here, here's another mockup (by Mathias), which doesn't have any confusing texts: http://bugzilla-attachments.gnome.org/attachment.cgi?id=187251 If we want to allow arbitrary text/icons, then IMHO this would be a better widget (the one on the top): http://wiki.maemo.org/images/2/2b/Fle_tut_app_menu_with_filters.jpg (that is, in fact, just a radio button with a special theming -- it's pretty much the same as the widget mentioned here in comment #7, except that it can have any number of options)
(In reply to comment #8) > What we could do for the GTK Switch is to turn the knob into the state > indicator. > IMO, it could work without labels too. > If someone is not familiar with this kind of a switch, they could quickly > realize that one side is ON(knob color) and the other side is OFF. Seems like > a better option than the I/O we use for the non-english locales. I'm not sure I like this: * The handle or empty space don't look very inviting to click or drag. I'm not sure how to replace the "grab grip" with an LED and still have it functional. * If we're going to skeumorph it up, I don't think many people would recognize a sliding switch with LED on it. It's not used all that often (expensive to manufacture a moving part with electrical contacts, etc.).
Created attachment 197810 [details] Two alternate solutions The core of the problem is that people aren't sure what the grip represents. Is the part that the grip covers "active" or is the part that the grip leaves open "active". One of the easiest solutions might be making it behave a bit more like an actual cheap hardware switch: slide the labels in and out when the switch animates. In cheap hardware switches, the entire switch is one plastic strip with contacts on either end and printed labels, and the entire switch animates. This also means that the color should not fade in, but instead slide like an actual hardware switch. Two other solutions are in the PNG file: "Overhang" tries to make it more clear by making the grip target larger, making it a bit more visible. You can play around with a web implementation of this solution here: http://magcius.mecheye.net/random/switch/ "Highlight Border" makes both labels visible, and shows the active state by the background color and a frame around the selected item. This might not be too skeumorphic, but with a good theme, you could make the highlight border look clickable and draggable.
Created attachment 197825 [details] [review] switch: Quick-code a demo alternative switch layout The code is incomplete, in particular toggling the switch via the mouse does not work correctly. But it should be good enough for adding CSS and evaluating the design in the context of larger applications. I'll make it commit-ready once we agree it's good design.
Created attachment 197826 [details] screenshot of demo
No, I don't think we agree
*** Bug 667202 has been marked as a duplicate of this bug. ***
The problem with hardware switches like a light-switch is that there is no easy way to tell by looking at the switch if the lights are on or off, you have to look at the side effects -> is there light in the room coming from the top? It takes learning to know at which position/state of the switch the light will be on, and still even then you might be wrong if the room is wired by two switches. Therefore the whole idea of having a switch with on/off state is problematic as evidenced by the confusion it causes. The solution to put the labels outside of the swtich, and to make the slider point towards the state it is in, is a very good solution. Still the problem is that a switch, or on/off state widgeted is modelled by two labels and a (pointing) slider. That is way too much possibilities for something that is either on or off. Now the slider can be in the state of "moving", and the reading of the state is made confusing since it is composed of two lables and two positions of the slider. Thats at least four total interpretations of something that must be modelled using two states only. In the GtkSwitch bluetooth example would be best solved by, Bluetooth <CheckBox> where the reading/interpreting the state of the checkbox is very easy, is it checked, it it unchedked? Two states, one widget. Not four possible interpratations and two widgets, slider and label.
Also, the proposal to put more lables, enabled and disabled next to the switch is even more confusing, what is enabled and disabled? Is the switch enabled or disabled or the thing it is supposed to affect? The same for adding lights to show if the switch is on or off, now you have slider, lables AND lights to try to convey the same thing! Even more confusion! The guidline should be changed to strictly use gtkswitches only for things that take time to take affect, that affect the system, and put the labels outside, with the slider pointing to the state it is in. A lightswitch also points to the state it is in. The slider would then not slider, it woudl flip. A flip switch with labels outside is the solution.
Last post I promise, See http://blogs.gnome.org/patrys/category/gnome/ Why isnt this fixed? Almost a year now, its getting embarrasing. Does anyone care?
Seems like we established there's a problem.
I just saw this alternative to the current GtkSwitch design: > http://hotot.org/static/hotot-0-9-8-5-released-2.png It is less confusing because the status is displayed directly on the slided button, not on the background; OTOH it relies solely on colour, which is less than optimal for daltonian people.
Here is a blog post with thoughts on the topic and some suggestions on how to deal with it, adding a comment since the bug is still in a NEW state. http://www.chrisnorstrom.com/2012/11/invention-multiple-choice-windowed-slider-ui/
*** Bug 697498 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Still relevant.
See also https://bugzilla.gnome.org/show_bug.cgi?id=763443
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/354.