Suggestions, Examples or Patterns for a Touchscreen Radio Button / Binary Control?
NOTE: Yes, I'm aware of the iPhone/iPad controls, but as I said, we can't use those, we don't have multitouch, which I think you need for the on/off control to work properly.
I'm working on a touchscreen application that does not have multitouch. We have a settings page where a user must choose a binary control, a radio button essentially, choosing "on" or "off." I've not been able to find any design patterns for this or really any good examples. I've seen people actually use big radio buttons, but it doesn't seem to translate well. I had two buttons, green for on and red for off with the selected one highlighted, but there's concern that people won't know to press "off" to turn it off.
I know really that testing will tell us what will work of course. But any suggestions here, or examples, would be greatly helpful. I'd like to have 2 or 3 options to test.
Get the feed
Comments
Hey Tom
I'm really fond of the on/off switch control from iOS. I don't have any testing data, but it strikes me as a particularly elegant solution. It's not dependent on multitouch, so it might work nicely for your problem.
On Friday, September 10, 2010, Tom DellAringa wrote: > I'm working on a touchscreen application that does not have multitouch. We have a settings page where a user must choose a binary control, a radio button essentially, choosing "on" or "off." I've not been able to find any design patterns for this or really any good examples. I've seen people actually use big radio buttons, but it doesn't seem to translate well. I had two buttons, green for on and red for off with the selected one highlighted, but there's concern that people won't know to press "off" to turn it off. > > I know really that testing will tell us what will work of course. But any suggestions here, or examples, would be greatly helpful. I'd like to have 2 or 3 options to test. > > > >
Yes, so am I - however as I mentioned I can't use that control since our touchscreen does not support multitouch.
I suppose it still could be an option as just push one side or the other, but I think it's less elegant. I also don't think that our demographic, which is a bit older, will get the control either.
By multitouch you mean (1) the user can only touch one point on the screen, or (2) the user can only touch at one spot at a time on the screen?
iPhone on/off switches tend to switch state where-ever you press/touch inside the control. Older people have never seen on/off-switches? i'm quite sure they are more used to those than standby-buttons.
What is it about that control that you feel requires multitouch?
If you can do it with a mouse, it aint multitouch
http://jqr.github.com/2009/08/05/iphone-toggle-switches.html
"I also don't think that our demographic, which is a bit older, will get the control either."
I would say that you might find the contrary to be true. The iphone toggle switch is a metaphor of real world switches, just because the iPhone popularised it's virtual application doesn't mean it is a)a new design, b)incomprehensible to someone who doesn't own an iphone or c)magic.
General rule: as a designer, if you catch yourself saying 'I think users would...' be prepared to defend or get caught red handed applying GD without the grounds to do so. That kind of statement is why there is bad software. Try applying the 5 why's principle.
Finally, if you do use that button in your design, be very careful where you put the labels, inside the control is a mistake (as found in that html page I linked to), either side of the control is a better choice imho.
regards /pauric
Hm. Thanks for the input. Yeah by multitouch, they can't do two actions - they cannot gesture on the screen either, I don't believe. For whatever reason that github link is blocked by Websense here - is it mirrored anywhere else.
@Pauric - I get what you are saying about how it mimics a real world switch. I guess I didn't think of it that way but I think you are correct. But since on our screens, they cannot slide it, it would have to function as a literal binary control - a toggle. Press it and it flips, press it again, it flips back.
Do you think that would be acceptable in your opinion? (Of course I could only verify by testing.) I'm leaning toward thinking it makes more sense than anything I've found so far.
If you're looking for a 'push' affordance then take a look at a rocker switch - although I'd say that's a less desirable affordance as the visual design is hard to get right.
http://www.abaecker.biz/images/abakus/preview/TAbRockerSwitch.gif
You're looking for alternatives to test I'd build mockups with the slider, rocker & two button. And I'll wager you the first is a clear winner.
Here's the funny thing about the slider (aka iPhone toggle) when applied as a straight toggle (as opposed to the slide action it visually affords). If the implementation ends up being as jrydberg describes above then users may initially try to slide it but quickly learn that simply touching the screen changes state. The only place I'd be careful applying this implementation and relying on this initial learning stage is in a modeless design - e.g. pushing the slider switches my pacemaker off. A minor consideration imho.
You're hinting at the implementation being constrained by a resistive screen and an elderly target market suggests to me that a stylus is not in the picture. So, if this is right then while you can actually read the slide action with a resistive screen it's hard to do that with a finger, even harder (I imagine) to do so if I were older, on meds, incapacitated etc.
I'm also going to postulate that even if you went the rocker switch route (gif linked above) and got the visual design nailed (for which you'd get a nobel prize for graphic design) any vision limitations with your user base rendering that work void.
Personally, I'd go with the slider toggle, apply the apple style (flat, high contrast) and I'd fully expect people to very quickly 'get it'. It's one of those interactions that, if new to it, you play with it and learn it really quickly. Just, for gods sake, do not put the labels IN the switch.
cheers /pauric
> Just, for gods sake, do not put the labels IN the switch. > > Strong agreement with this one -- my team just learned it the hard way a couple of weeks ago. It only took two actual uses on touch hardware (not mouse on screen) to realize our mistake.
Paul
On Sat, Sep 11, 2010 at 12:36 PM, probertson <paulslists@gmail.com> wrote:
I've also wondered why the hell Apple (and others) keep putting the labels inside the slider.On the iPhone I could see that space is a constrain, but other people are re-using the
control for desktop applications.
For example, the UX guys from Spotify said this when asked why the labels are inside the slider:
"I have real-world switches like that. For instance the lock switch on the iPhone or the power button of a photo strobe."
Johan: "For example, the UX guys from Spotify said this when asked why the labels are inside the slider:
"I have real-world switches like that. For instance the lock switch on the iPhone or the power button of a photo strobe."
A classic example of this physical > virtual fubar is the quicktime volume control: http://multimedia.cx/eggs/images/quicktime4.jpg
Designers rightfully reuse a well recognised physical design for a virtual interaction lock stock and barrel without also enhancing the design/interaction with functionality that the virtual world afford you.
Lifting metaphors is fine, to a degree. However, users interpret and process the physical and virtual worlds differently - basic context of use stuff. When interacting with software I expect certain affordances to attract my attention when necessary/appropriate - changes not possible in the physical world. The youtube volume control is not possible in the real world.
Familiarity and consistency is fine but understand that physical design solutions have certain constraints and you have an opportunity to improve. Intuitiveness trumps consistency - but be prepared to lose that argument.
/pauric
btw, while you can read both the slide and push with a resistive screen I would disable slide and force users to learn one method for controlling the affordance. Slide can be problematic and as the graphics afford a slide action some users may not learn the simpler/easier push input method and end up getting frustrated with your design.
/pauric
Thanks Pauric. I agree about the toggle being very tough to get right. And no, no stylus. I'll give it a go. thanks!
David, the reason I advocate for text labels to the left and right of the control (as opposed to the inside) in the context of this older user base is as follows
Existing 'iphone' convention: [On] label is exposed, 'button' is to the right obscuring the off label. To turn the feature [Off] you must slide the button from right to left, to the [On] positon. See where I'm going with this? The is compounded with the visual design, the recessed label is the active state, the raised button is in the space of the inactive state.
Ok, so I'm exaggerating the cognitive twist a user must learn... to turn something off you must drag the button to the on position and expose the off label. And while you might be so comfortable with this to the extent you do see the problem, our testing has shown that people pause when asked to verbally state what they beleive design implementation is telling them. Once interacted with and learned, some users go through what I call 'cognitive fliping' (I know there's a more formal name for this) This is where you learn an interaction that is counter intuitive but when you return to the interaction after a period of time you remember there was a twist but you forget which way the twist must go and end up with a 50/50 chance of success.
If the op is under space restrictions, by all means put the labels in the button but given the target market and bespoke hw I'm guessing neither is this a wise choice nor necessary.
regards /pauric
Hi Tom,
This is an example of ON/OFF switch from a real touch-screen kiosk: http://interux.com/images/On_Off_Switch.gif
I have no data on its usability…
In my practice, I have designed a couple of touch-screen applications and always used buttons instead of radiobuttons, checkboxes, dropdowns etc., eg:
[ Use some functionality ]
[ Do not use some functionality ]
Pressing a button leads to the next screen.
Regards,
Ivan
Thanks for the great conversation everyone. The issue of the labels in or out is very interesting. I did in fact use the iPhone control in another application, and I have the labels in. We haven't had the opportunity to test it yet though.
For those of you promoting labels out, are you saying you'd have both "on" and "off" - one to each side, or just the singular label of the currently selected mode? i.e., "off" when the switch is off?
We originally had the label inside on ours. When it was off (switch to the left) the "off" label was on the inside right. When it was on (switch to the right) the "on" label was on the inside left. (So whatever label was showing represented the current state.) The problem with this was you end up dragging the switch toward the word "off" in order to turn it on -- which was counter-intuitive. Moving to having the labels on the outside and always visible made an obvious difference for us.
Some possible factors that might have made it problematic in our case are: - This was for a tablet application, and the on/off switch was the only element on the screen (aside from some branding), so space wasn't an issue for us. Consequently... - The on/off switch was a large slider (roughly 3 inches long). A key reason for making it large was because changing the value of the switch actually turned another computer on or off -- a time consuming process obviously -- so we wanted to require a very deliberate action.
Paul
Tom: "For those of you promoting labels out, are you saying you'd have both "on" and "off" - one to each side, or just the singular label of the currently selected mode? i.e., "off" when the switch is off?"
Forgive me, rather than tell you what I think would be the correct solution I'd like you to a little visual thinking exercise. Pick one of the designs and;
* Imagine you are one of your users, refer to a persona if you've created them.
* State aloud, I've arrived at this screen because... or my goal in this screen is..
* Picture the button, focus on the image, interact with it in you mind.
* Write down any thoughts/concerns you had
Repeat with each design solution. Depending on your visual thinking strengths you may need to take a couple of passes at this, if you're still not seeing an issue then try sketching out both designs and running through the exercise as a standard walkthrough evaluation.
hth /pauric