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?)
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.
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.
I think these look incredible and I can't wait for a usable version.
[Edited for clarity]
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")
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.
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.
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."
Edited: I distinctly remember being confused about what kind of control they were the first time I saw them.
In the digitl world? A well thought out and presented slider might actually encourage engagement with a feature, overrelying on abstract radio buttons.
"OK, it's displaying a pause icon - is that telling me it's paused, or that I should click it to pause?"
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.
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
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.
Given that a click is simpler and quicker than a drag, I think this suggestion is a worse user experience than a tab bar.
And who said anything about dragging? I read the whole post and was under the impression that the selection was made via click...
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.
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.
In (continental) Europe, I've never seen it. And I find this type of buttons very confusing.
Also your solution becomes more of a list than a toggle. There are already a lot of similar designed selectable lists.
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
On | | X | Off
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).
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.
The article shows: [OFF [ ]]
iOS: [[ ] OFF]
Reminds me of this little change that Apple made and then quickly reverted: