5

Our web app allows users to switch between (currently 3, potentially more in the near future) different "contexts". For example, they could choose to view the app from the point of view of a "Corporation", "Small Business" or "Single User". Each of these "contexts" provide something additional to the application as a whole, targeted (obviously) to a specific kind of user.

Currently, we use a drop-down menu that allows our users to swap between these "contexts". Our Project Manager has proposed using radio buttons instead of the drop-down approach. To me, radios just seem wrong in that context. I see radios as a "form element", and certainly not something that belongs in a header. I spend most of my time on StackOverflow, which clearly isn't the place for this kind of question, so I just wanted to get some input from some seasoned UX guys.

What do you think?

Improve this question

6 Answers 6

Reset to default
3

Drop-down boxes tend to be the more common pattern, and because most 'view controls' try to use as little viewport estate as possible, the space-saving properties of a dropdown are useful. If a radio button is laid out vertically, it'll take up a lot of space, but if it's horizontal, it's hard to scan, because users can't seek left to right as effectively as top to bottom.

So, the key difference is that:

  • radio buttons make all choices visible constantly, but are harder to scan
  • dropdowns are space efficient and attractive, but don't show all possibilities at once

Only you can really say, knowing your context, which set of advantages trumps the other, but as your 'views' rarely change, I can't really imagine how seeing all choices would help. A radio button will, as I say, take up space, which means you'll have to change your form should you start adding items to the list, or other elements to the control - and that change creates cognitive friction for your users. Unless there's a compelling reason, stick to the dropdowns.

Improve this answer
2

Perhaps you could ask the PM if any of the users are sometimes utility companies, sometimes commercial entities, and sometimes residential users.

If in fact, as seems likely, users align with one category only, they'll probably want to set it and forget it.

Improve this answer
1
  • 1
    Our users are most certainly "one type of user". Very rarely are, say, Utility users going to want to do stuff from a Residential point of view. I agree that set-it-and-forget-it is the best bet here.
    – Chris Cashwell
    Commented Nov 1, 2011 at 14:12
1

Dropdown is a much better option. I see two main reason for using them:

1) Convention. Other websites have already trained your users to work with this setup.

2) Since you are planning to add more options, radio buttons can run out of space pretty fast, considering that you have them in the header. Dropdowns offer much greater flexibility.

I try to limit the use of dropdown, but in your cases, they are a much better option.

Improve this answer
1

What is the rational you have been given for wanting to change from drop-down to radio buttons? Are users finding it confusing at the moment? If there's a valid reason for changing then it would be worth investigating why.

The problem you'll have if you try to switch to radio buttons in the header is that it's going to be harder to tell which radio button belongs to which label. For example, at a glance is it the Commercial Entity or Residential User that's selected here:

Radio Buttons

Also, you'll find it difficult making space for when you add extra ones in at a later date. No, stick with the drop-down, it's more 'future proof' allows longer labels and takes up much less space.

Improve this answer
2
  • 1
    The rationale was that he wanted to change things up. There wasn't any real thought about it. I agree that radio buttons can be tough to associate with the correct label for the user, resulting in the wrong selection sometimes. Space is also a concern of mine. The way I see it (and the fact that the drop-down is very clear in its function), there's no reason to switch to a potentially less-clear concept.
    – Chris Cashwell
    Commented Nov 1, 2011 at 14:27
  • 2
    Lets just change things is rarely a good start to any design change.
    – Schroedingers Cat
    Commented Jan 17, 2012 at 16:06
1

Jquery's Button function makes radio buttons look like nice big buttons which still show a mutually exclusive state.

Here's the default style, though it has poor "pressed" affordance:

enter image description here

As Matt Rockwell indicated these are very common in mobile apps to keep "screens" in a single logical container. You're doing a similar thing with your website, but the jquery buttons let you have a good looking (normal radio buttons look too much like a form control) and customization solution that has the same functionality as radio buttons.

Improve this answer
0

Twitter uses a "segmented control" as it is termed by Apple (in this case it is used in conjunction with a search field - together called a "scope bar") , but really what it is is a collection of radio buttons. This works very well, and Facebook uses this as well on its mobile app.

enter image description here

This is easily understandable, clean and a great solution to your problem, unless the number of options available exceed 5 or 6, then a drop down would be more appropriate.

Improve this answer
2
  • I agree that segmented controls can be nice for mobile apps, but that isn't the context we're working with. I'm not sure there's enough precedent for it on the desktop, and I don't want to argue something that might be confusing for users. Any examples of this in use outside the mobile environment?
    – Chris Cashwell
    Commented Nov 1, 2011 at 14:31
  • Try apple.com :) They use it for their nav, but the concept is similar.
    – Matt Rockwell
    Commented Nov 1, 2011 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.