Show HN: Non-Confusing, Visually Correct Slider Toggle UI(chrisnorstrom.com)
chrisnorstrom.com
Show HN: Non-Confusing, Visually Correct Slider Toggle UI
http://www.chrisnorstrom.com/2012/11/invention-multiple-choice-windowed-slider-ui/
35 comments
...now seriously, what's wrong with good ol' radio buttons and check-boxes? they seem 100x more intuitive and with some effort (yeah, more than it should...) you can make stylish versions of them that will match you design
I don't think the author was saying this should be a replacement for radio buttons. It's more of an informative exercise in visual design, analyzing the problems of one style and how it could be improved.
The entertaining bit (similar to the standard floppy-disk "Save" icon), is that most people who have grown up with the web always present... have never seen a radio with true "radio buttons".
Oh sh*t. It all makes sense now.
I'm kind of ashamed to write this, but I had never realized what "radio button" actually means.
I grew up knowing what they were (I was born in the 80s), but English not being my primary language, I never considered that "radio button" might mean "the kind of button you have in a radio". And I never felt the need to look for a definition :)
(are you done laughing?)
I'm kind of ashamed to write this, but I had never realized what "radio button" actually means.
I grew up knowing what they were (I was born in the 80s), but English not being my primary language, I never considered that "radio button" might mean "the kind of button you have in a radio". And I never felt the need to look for a definition :)
(are you done laughing?)
To be fair, English is my primary language and I've been doing web development for 10 years and I didn't know why they were called radio buttons until very recently!
I also grew up knowing what they were, and even as a native English speaker, I didn't make the connection to old car radios until I was an adult. I always figured it had something to do with "radius", since they have always (inexplicably, come to think of it) been presented as little circles.
I really think this idea that people haven't seen old technology is somewhat over-sold. I mean, I know about the Beatles, and I wasn't alive in the sixties, I know a good bit about classical antiquity which was thousands of years before my birth, I'm aware of room-sized computers from the '50s, and mechanical computers before that, and yes, I've played with old radios that have radio buttons in my dad's old cars, at thrift stores, and in my dad's 8-track player.
Don't car radios still have station preset buttons, e.g. labelled 1 through 5, with one (and only one) being lit when you press it?
They still have preset buttons, but many that I've encountered have no visual indication that one is selected.
Ah, true, mine don't light up.
I find it quite funny. The author started by demonstrating that sliders are inappropriate when representing 1-of-N choices. I agree. Then he proposed a visual change that makes things better. This change makes the GUI element look like and work like radio buttons. The only step remaining is to stop calling this GUI element sliders and start calling it (fancy) radio buttons.
I see a significant difference between radio buttons and the proposed solution. The change of state with radio buttons require a simple pointing and click. While with the sliding frame, a pointing and a constrained sliding operation is required.
When using a mouse the radio button is the most simple and efficient widget. But when using touch screens, the sliding frame seems a better solution because it avoids accidental state change, while still being a natural and intuitive operation to do with the finger.
So I would say that for touch screen devices (especially phones) the proposed solution is excellent and better than radio buttons.
When using a mouse the radio button is the most simple and efficient widget. But when using touch screens, the sliding frame seems a better solution because it avoids accidental state change, while still being a natural and intuitive operation to do with the finger.
So I would say that for touch screen devices (especially phones) the proposed solution is excellent and better than radio buttons.
That's totally a good point. Following this idea, in touchscreen devices there should be only one widget for both radio-button and checkboxes (which can be represented as boolean sliders)
I think the big difference between a slider and radio buttons is how much screen space is taken up. For radio buttons, you have the text description ("ON", "OFF") along with an indicator / selector to the side. Whereas the slider combines these two elements. This is more important on smaller screens, where the text / selection area would have to be enlarged to accommodate finger input.
"fancy radio buttons" doesn't slide off the tongue quite as well though.
I thought the same thing. Radiobuttons convey much better that there is a single choice to be made among a list of options. Especially if you have a list of multi-word options, you really really should not be using those radio buttons.
For his example of the different game flavors, it does not make sense at all to have a slider, simply have users click on the option they want to have, and jump to a next page to ask for details and confirm everything. You need to have a confirmation page anyway.
For his example of the different game flavors, it does not make sense at all to have a slider, simply have users click on the option they want to have, and jump to a next page to ask for details and confirm everything. You need to have a confirmation page anyway.
Really? I think your above-average knowledge of the intricacies of web design may actually be misleading you here. My guess is that normal people can't actually tell radiobuttons from checkboxes until they click around and find they can't select two options at once.
I think these look incredible and I can't wait for a usable version.
[Edited for clarity]
I think these look incredible and I can't wait for a usable version.
[Edited for clarity]
> normal people can't actually tell a checkbox from a radiobutton until they click around and find they can't select two options at once
this may be true for a certain definition of normal, but the point for this game example is that you don't need EITHER: just have the user click on the desired option and let them be lead to the next/confirmation page... drop dead simple 'cause, as wise men have said before: "no UI" > "less UI" > "your UI" (where ">" = "is better than")
this may be true for a certain definition of normal, but the point for this game example is that you don't need EITHER: just have the user click on the desired option and let them be lead to the next/confirmation page... drop dead simple 'cause, as wise men have said before: "no UI" > "less UI" > "your UI" (where ">" = "is better than")
Hmmm, I think you and jvdh are right. Simple selection is better than a slider in that case. In general though, I still don't like radiobuttons:)
Thanks for sharing the UI quote. I hadn't heard it before and I immediately see the, ah, practical application it has to my own work.
Thanks for sharing the UI quote. I hadn't heard it before and I immediately see the, ah, practical application it has to my own work.
Well, there's no indication the usable click area is limited to the slider. In the games setup, it would make sense that clicking anywhere in the option might trigger the appropriate slider change event.
It adds a single "continue" click from what you seem to propose, but if the rest of the checkout process is streamlined, that may be acceptable.
It adds a single "continue" click from what you seem to propose, but if the rest of the checkout process is streamlined, that may be acceptable.
Every slider implementation I've seen on the web has been inspired by sliders in iOS, where they provide a bigger touch target. iOS sliders also give considerable information about their current state: the word "OFF" is in grey text on white, and "ON" is in white text on a vivid blue background.
I agree that they're not really appropriate on desktop browsers, and I haven't really seen an implementation of them that impresses me or gets it completely "right."
I agree that they're not really appropriate on desktop browsers, and I haven't really seen an implementation of them that impresses me or gets it completely "right."
The iOS slider is so good, that one site I use literally just screenshotted its on and off positions... and used them as a checkbox.
While they provide a bigger touch target, I don't think they are intuitive.
Edited: I distinctly remember being confused about what kind of control they were the first time I saw them.
Edited: I distinctly remember being confused about what kind of control they were the first time I saw them.
What did you try? There's only really two verbs in iOS (tap and drag), and they both work.
I still find them confusing.
Perhaps (as pure speculation) it's cognitively less taxing for average users to interact with an element that reminds them of a physical switch.
I'm imagining a voting paper made out of cardboard, where you slid a piece into place before stuffing into a ballot box.
In the digitl world? A well thought out and presented slider might actually encourage engagement with a feature, overrelying on abstract radio buttons.
In the digitl world? A well thought out and presented slider might actually encourage engagement with a feature, overrelying on abstract radio buttons.
The windowed slider panel is a great idea. I couldn't agree more with the author's assessment of how confusing normal switches as shown can be, as I've felt the same confusion in the past, and know others do too. Interesting post and great ideas.
I find similar confusion when confronted by Play/Pause buttons on video controls, before the video has loaded and started playing.
"OK, it's displaying a pause icon - is that telling me it's paused, or that I should click it to pause?"
"OK, it's displaying a pause icon - is that telling me it's paused, or that I should click it to pause?"
Indeed. I've got an enormous monitor; surely they can find another 32x32 pixels for separate play and pause buttons.
No, the player should not show play or pause while the video is loading. There are more than two states the player is representing with only two icons. Adding separate buttons would not help that.
Yes, it should, because I might want the video to play immediately after it buffers, or I might want it to just buffer and press play in a few minutes.
Having a play and a pause button which to push to indicate the current state of the video while it buffers is very useful.
Also, to the parent, a button should display its action, so a "play" button will play and a "pause" button will pause. Except when the interface is designed by a web designer.
Having a play and a pause button which to push to indicate the current state of the video while it buffers is very useful.
Also, to the parent, a button should display its action, so a "play" button will play and a "pause" button will pause. Except when the interface is designed by a web designer.
To me the whole thing that makes it confusing for me is that real slider switches are labeled externally:
Putting the label under the sliding part of the control is what makes it confusing.
EDIT: just noticed that huhtenberg posted the same suggestion
+-------+
OFF | |XXX| ON
+-------+
Putting the label under the sliding part of the control is what makes it confusing.
EDIT: just noticed that huhtenberg posted the same suggestion
>However, there are a few times when a slider is warranted and even a Better UI choice:
>
>To switch back and forth between two states that both need to be described, such as a slider in your blog’s control panel with “Published | Unpublished” as the choices for the article draft you’re working on.
But we already have a UI element for that. In HTML, it's known as a "select" input, and it works very well, is extremely compact, and is already familiar to your users.
In fact, if you set the "size" attribute, then it even has the "window" functionality described in this article. The window typically is shown with no border, and it doesn't look as fancy, but other than that, it is exactly the same concept.
But we already have a UI element for that. In HTML, it's known as a "select" input, and it works very well, is extremely compact, and is already familiar to your users.
In fact, if you set the "size" attribute, then it even has the "window" functionality described in this article. The window typically is shown with no border, and it doesn't look as fancy, but other than that, it is exactly the same concept.
His "solution" is just a tab/nav bar with different styling:
http://twitter.github.com/bootstrap/components.html#navbar
Given that a click is simpler and quicker than a drag, I think this suggestion is a worse user experience than a tab bar.
http://twitter.github.com/bootstrap/components.html#navbar
Given that a click is simpler and quicker than a drag, I think this suggestion is a worse user experience than a tab bar.
They are slightly similar in design, but solving two completely different problems with different core functionality.
And who said anything about dragging? I read the whole post and was under the impression that the selection was made via click...
And who said anything about dragging? I read the whole post and was under the impression that the selection was made via click...
I was under the impression that part of the beauty of the design is that a click from my desktop would be supported as well as a touch and drag on my tablet. The UI intuitively supports both mediums.
This seems so obvious in hindsight, yet this isn't what everyone comes up with!
You have to think of the constraints that informed the original design. There's very little horizontal space on iPhone and iPod touch, 320 points to fit a descriptive label and the control.
So labels on the sides don't work because of space constraints, on iPhone anyway.
The windowed version is also less space efficient than the stock iOS control but I think it has merit because it shows all possible states. What I'd change is reverse the tinting, to make the active state more visible and the other states shaded.
So labels on the sides don't work because of space constraints, on iPhone anyway.
The windowed version is also less space efficient than the stock iOS control but I think it has merit because it shows all possible states. What I'd change is reverse the tinting, to make the active state more visible and the other states shaded.
http://jsfiddle.net/LWFg3/6/ here you go. I call it ouija. Will probably bundle it as a component shortly.
Lockitron also showcases the slider issue in their product video: https://www.youtube.com/watch?feature=player_embedded&v=...
It is nice, but to my mind, a slider is different to a switch. The classic "on-off" switch that the author takes on is like a light switch - to that end, it does its job pretty well, I think, telling you what state it is in.
I don't know about you, but I rarely look at the labels on a light switch. When I find light switches that go side-to-side, I usually have to rely on my knowledge of the current state of the light rather than the position of the switch. Either way, you have to agree that the confusion the article speaks of is a reasonable one, and making interfaces that are resilient to be confusing is the job of the UI designer.
I don't find the two-position slider switch confusing at all; it looks and behaves like a physical object - one of these: http://cdnsupport.gateway.com/s/POWER/SHARED/q0012508.jpg
The OP's controls are slightly more obvious visibly, but don't look as much like common physical switches and are more visually cluttered. The color-changing version doesn't resemble anything I've seen in the real world, though I'm sure it's possible to do.
The OP's controls are slightly more obvious visibly, but don't look as much like common physical switches and are more visually cluttered. The color-changing version doesn't resemble anything I've seen in the real world, though I'm sure it's possible to do.
Even the physical object is ambiguous -- do I slide it to the side with the label that represents the state I want, or does the label represent the state?
Except this design does not exist everywhere ...
In (continental) Europe, I've never seen it. And I find this type of buttons very confusing.
In (continental) Europe, I've never seen it. And I find this type of buttons very confusing.
It certainly was non-confusing to try and slide pictures of sliders.
I just figured (until the end of the article) that it just didn't work on Android.
Totally agree. I find it so difficult to tell my parents to switch an iPad slider to ON or OFF, so I simply tell them to make the capsule blue or gray.
I think the way Apple is doing this is much more elegant. The on state is visualized by a contrast background color and the off state is just a gray background. Much more simple and much more visible. This proposed solution with a slightly lighter color as indicator of selection is not very good, sorry.
Also your solution becomes more of a list than a toggle. There are already a lot of similar designed selectable lists.
Also your solution becomes more of a list than a toggle. There are already a lot of similar designed selectable lists.
Someone needs to send that link to the Gnome 3 devs :)
Take a quick look at ICS/JB on Android, which has already solved this problem.
The current state is written on the sliding bit, clicking anywhere will toggle it, but correctly show the current state.
The slider will also glow blue if it is on the ON state, and revert to grey on the OFF position.
See here: http://i45.tinypic.com/263jypz.png
The current state is written on the sliding bit, clicking anywhere will toggle it, but correctly show the current state.
The slider will also glow blue if it is on the ON state, and revert to grey on the OFF position.
See here: http://i45.tinypic.com/263jypz.png
A simpler option for a binary choice is this -
+-------+---+
On | | X | Off
+-------+---+Scroll down to the end of the article, or search for "Another Alternative".
It's a long article, so it should've started with the simpler options, shouldn't it? :)
Part of the point is that this solution is known to pretty much everyone already, yet it's usually rejected for the reason people choose the unintuitive alternatives up top: It takes up more space for the same font and slider sizes.
I tend to prefer that solution too (or if you're really cramped for space, the old AmigaOS "MX gadget" which shows only the selected state, plus a small icon to indicate it will cycle between states).
I tend to prefer that solution too (or if you're really cramped for space, the old AmigaOS "MX gadget" which shows only the selected state, plus a small icon to indicate it will cycle between states).
Not necessarily, it is better to draw some attention at the beginning so that it motivates reader to keep reading.
If you're interested in adding the left/right style example and you're already using jQuery UI, you can use the ones I built here that inherit your slider styles:
http://taitems.github.com/UX-Lab/ToggleSwitch/index.html
http://taitems.github.com/UX-Lab/ToggleSwitch/index.html
I like. The vertical variant looks very similar to a <select> element with the size attribute set. Maybe you could take some clues wrt styling from these elements? Not sure how that would look in a horizontal version though.
Wholeheartly agree. I made a mockup of just this issue a few weeks ago: http://dribbble.com/shots/747199-Night-Day-Slider-Switch
Not a bad solution, but I'd still prefer a red or green state (In my experience, color trumps shape).
Of course that doesn't work for more than two options, but I have a hard time finding a decent use case for that anyway.
Of course that doesn't work for more than two options, but I have a hard time finding a decent use case for that anyway.
8% of men are red green blind.
Sweet! This is quite nice. Good job. The best part about the solution is the consistency for different type of options like simple on/off options to ones which require long descriptions.
I just gave up on the idea of using a regular slider to toggle between 'Any' & 'All', because I didn't want the selected text to be hidden. This solution would be perfect!
[deleted]
I think this is more elegant than a radio button.
I agree, but elegance cannot replace functionality. Apart from the touchscreen perspective (https://news.ycombinator.com/item?id=4743643) I would use only plain old radio buttons.
[deleted]
It's certainly confusing as is, but a good designer will use other design cues like color and depth to reinforce the state.
Much better, it's obvious in hindsight. Now if you could work some magic on those horrible range inputs…
Will this work in terms of accessibility?
Congrats, you can add a paragraph about related work and an Usability section about arbitrary observed metrics on test groups and submit to CHI :)
[deleted]
The sliders on the article seems inverted from iOS's sliders.
The article shows: [OFF [ ]]
iOS: [[ ] OFF]
The article shows: [OFF [ ]]
iOS: [[ ] OFF]
Congrats. You've invented the cursor.
Wow. After all these decades and countless people we would have seen something like this before.
Reminds me of this little change that Apple made and then quickly reverted:
http://appleinsider.com/articles/11/04/29/inside_mac_os_x_10...
Reminds me of this little change that Apple made and then quickly reverted:
http://appleinsider.com/articles/11/04/29/inside_mac_os_x_10...
I really liked that design. I was really pissed when they changed it to something (IMO) inferior later on... :(