Suggestions, Examples or Patterns for a Touchscreen Radio Button / Binary Control?

10 Sep 2010 - 9:24am
3 years ago
17 replies
2421 reads
tdellaringa
2006

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.

 

Comments

10 Sep 2010 - 10:05am
Christopher Rider
2009

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. > > > >

10 Sep 2010 - 10:19am
tdellaringa
2006

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.

10 Sep 2010 - 12:04pm
jrydberg
2010

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.

 

10 Sep 2010 - 12:38pm
.pauric
2006

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

 

10 Sep 2010 - 12:59pm
tdellaringa
2006

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.

10 Sep 2010 - 2:01pm
.pauric
2006

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

 

10 Sep 2010 - 4:05pm
probertson
2010

> 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

11 Sep 2010 - 2:05pm
jrydberg
2010


On Sat, Sep 11, 2010 at 12:36 PM, probertson <paulslists@gmail.com> wrote:

> 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.


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."



Paul

((
11 Sep 2010 - 3:28pm
.pauric
2006

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

10 Sep 2010 - 2:09pm
.pauric
2006

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

10 Sep 2010 - 3:08pm
tdellaringa
2006

Thanks Pauric. I agree about the toggle being very tough to get right. And no, no stylus. I'll give it a go. thanks!

10 Sep 2010 - 6:59pm
Dave Malouf
2005
Tom, I think you are mistaken about the capabilities of your screens. there is nothing preventing a resistive screen from doing a slide. NOTHING. If someone tells you otherwise it is b/c A the drivers you are using are dated (and I mean pre this century, or B your engineers are lazy. if you just look at the class PalmOS interface from treo days (heck from Palm Pilot days) there are tons of applications that use a slide. Heck a scrollbar is a slide widget push, hold, move. Drag & drop is a slide gesture. Now, does that mean that the iOS binary control is the only way to go? Heck not. Android's method is really interesting as well. The other way to go is the see-saw approach. It is a toggling switch where the unselected side is perceived as raised, and the selected side is depressed. It is a classic analog metaphor that anyone regardless of age can get easily. Also, is your binary boolean? i.e. on/off or yes/no ... you can have a single button represent just the positive state. This does not work if your binary is not direct opposites of a positive/negative nature though, such as right/left. Yes, they are opposites but right is not the "on" of left. But using a checkbox (or a single button w/ a state change) can work quite well. I'm nots sure I agree w/ the label placement that pauric is suggesting, as I really like the labels inside my iOS controls right now as they save space and make things totally clear to me. But again, no data. -- dave
11 Sep 2010 - 8:48am
.pauric
2006

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


12 Sep 2010 - 2:43pm
Ivan Burmistrov
2009

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

14 Sep 2010 - 10:45am
tdellaringa
2006

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?

14 Sep 2010 - 5:05pm
probertson
2010

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

14 Sep 2010 - 10:04pm
.pauric
2006

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

Syndicate content Get the feed