Replace radio-input with "buttons"? (web forms)

Question

Is it good (or okay) UX to replace radio input fields with something that looks kinda different (please look at the image to see what I mean). I think most people will understand that they have to click on one of them, but I'm not that sure.

'Female' and 'Male' have radio buttons under the hood which are not displayed.

Demo image:

Live demo: http://fiddle.jshell.net/s5uEX/show/ (Tested in latest firefox. Semantically correct and non-CSS3/non-js version (w/o shadow and so on) will be there later, too, of course)

Edit:

I changed a lot based on your replies (thanks!). http://fiddle.jshell.net/ge8Su/show/ - It does now look more like regular radio buttons. In my opinion a good compromise between user expectation and what I wanted to achieve.

Answer 1

I would try the best of both worlds, make it good for touch and desktop by adding the radio buttons to you button style:

Answer 2

So I tap the Repeat Password control and the app repeats my password for me?

That’s the problem: when all your controls look the same then the user doesn’t know for sure how to interact with them anymore. You either have to include text instructions, which consume space and slow the user, or the user has to stop and think about how to use your interface (“Hmm, it already says Female and Male, so I guess I select one rather than type something in, and I guess it sets a field, but maybe it takes me to a separate page for additional Sex information… I guess I’ll just have to find out”). You have a TAMIDS interface: Tap Anywhere; Maybe It Does Something.

Different controls should look different. Controls like text boxes should look like standard text box controls, controls with radio-button behavior should look like standard radio buttons, controls with check box behavior should look like standard check boxes, etc. Standard appearances should be used in order to leverage user experience so users can anticipate the behavior. I wouldn't recommend non-standard appearances even if they do distinguish the controls because then the user has to go through the effort of learning the new "code." How close to the standard does the appearance have to be? Close enough to be instantly recognized. For a radio button just about any circle with a dot inside should do, but generally the easiest and safest approach is to go with the control's default appearance.

I don’t see any advantage to making these radio buttons look like text fields. At least in the desktop world, the caption as well as the radio button itself is sensitive to input, so it’s not a issue of target size. Even if testing shows no detriment to response time to selecting sex in your case, failing to abide by standards undermines their usefulness, making it more likely users will be confused in other situations when it’s more ambiguous.

Answer 3

For a mobile form, I like it. Easier to tap on for touch devices, and fairly intuitive (for me at least). That will likely improve with the shadows that you intend on adding.

I'm not sure if it's a better alternative to radio buttons for non-mobile forms, but I doubt that it would cause major issues. Of course, you need to test this to be sure.

One interesting issue you may face is that it is significantly clearer that "male" and "female" are buttons if one of them is selected already. You run into the problem of choosing a default state, but then how are you sure that someone actually wanted it to be the default value, or they just left it filled in by mistake. Also something to test for.

Answer 4

Having tried it, I think it is clear enough, especially as you move over it, and the "buttons" highlight. I have no idea what it would be like on a mobile, but I think it is clear and obvious enough.

In essence, what you have done it taken the standard radio button control and skinned it - something that used to be very common, and sometimes irritating. However you have done it well here, and the controls have reasonably clear affordances, because they appear similar to buttons.

So I think it works.

Answer 5

There are a couple of issues which can be remediated with good visual design:

• which of these options is currently "on"?
• are the choices mutually-exclusive (i.e. are these radio buttons, or checkboxes)?

For the first issue I have seen treatments which were ambiguous. If you have 3 or more options to select from then its usually pretty clear which is the selected option. However, see issue 2 for environments that confound this.

For the second, you can imagine using a similar treatment for day of week selection: [ Mon | Tue | Wed | Thu | Fri | Sat | Sun ] where each day could be independently and non-mutually exclusively turned "on". It's compact and neat and minimises clutter ... but means a display of [1-1-2] is now ambiguous as to whether state "1" is "on", or state "2" is "on".