UI Design: single-selection lists

| | Comments (8)

So it recently came to my attention that some people are confused about single-selection lists and how to properly implement them in your UI. I'd like to take a moment to discuss my thoughts on the subject.

A single-selection list can be implemented in many different ways. The most common ways that you'll see this concept implemented are:


  • As a group of radio buttons. The radio buttons only allow a single option to be selected within the group, while showing all of the options up-front.

  • As a single popup menu (AKA, read-only ComboBox for those of you coming from a Windows background). This option allows one selection within the data listed, but it requires the user to interact with the control to see the list.

  • A single-selection list box. This option displays the list of choices which the user can then select.

Now that you know what the choices are, here are the pros and cons of each choice.

Radio Buttons
Pros


  • Shows the user all of their options up-front. This lets a user quickly scan their choices and make a decision about which option they'd like with a minimal amount of physical interaction with the interface.

  • Easy single-select keyboard shortcuts by using keyboard mnemonics.


Cons

  • Because it shows all of the choices up-front, the UI can become cluttered quickly if there are a lot of choices.

  • Not all platforms support keyboard mnemonics (for instance, the Mac). Also, the more UI elements you have, the less mnemonics available for you to use. Between all the controls and top-level menu items, you only have 26 keyboard menmonics (assuming an English-language UI) to chose from. If you have more than 26 UI elements in view, then you run into mnemonic problems.

Popup Menus
Pros


  • Can show the user more options while using less UI space by displaying all of the options as a list only when the user interacts with the control. Otherwise, the control only takes up the same amount of space (roughly) as an EditField.

  • Has quick keyboard interaction for displaying the options (hitting Alt+Enter), as well as selecting the options (the first letter of the item in the list is essentially a mnemonic, regardless of whether the list is popped-open or not).


Cons

  • Requires the user to interact with the control in order to display which options are available

  • Not all platforms allow quick user interaction with the keyboard by default (such as the Mac).

List Boxes
Pros


  • Displays much of the user's choices up-front, so the user can scan their choices easily

  • With a marginal amount of effort, can have easy single-selection keyboard interaction by using the first letter of the row as a mnemonic.

  • Uses up less space than a group of RadioButtons to display the options

  • Can get user focus via the keyboard on all platforms (including the Mac) by default.


Cons

  • Doesn't always display all of the information to the user. When the list gets too long, then the user must interact with the listbox to display the rest of the options.

  • Marginal effort is still effort -- you have to work to make the single-selection behavior a viable solution.

  • Uses up more space than a PopupMenu to display the same number of options.

  • There's no visual distinction between single-selection and multi-selection listboxes. This can be confusing to users because they may attempt to select multiple items from the list (or want to select multiple items since the listbox doesn't set their expectations appropriately).

Ok, so those are the facts. Time for the theory/speculation.

Presenting too much information to the user tends to overwhelm them into thinking they can't understand an interface. A great example of this would be the Office preferences dialog. Multiple rows of tabs, each one crammed with options for the user to select from. Because of this, a radio buttons and list boxes may not be an appropriate choice for single-selection lists.

If you have too many radio buttons, then you devote too much UI to a single list of information. Generally speaking, the purpose to a dialog is to present related pieces of information (the plural form being the key here). So taking up a large percentage of the UI for a small percentage of the information is poor use of space. Aside from it being overwhelming, you're putting the emphasis on that list of choices, and not on the overall goal of the dialog.

Similarly, a listbox suffers from the same problem as the radio buttons do. You're still presenting the user with a lot of choices, but you're putting them into a more concise interface element. The listbox takes up less space within the overall interface, and so the options "fade" into being just another part of the dialog. To this end, the listbox is a better choice than a large number of radio butons because it doesn't detract from the design goals of the dialog.

However, a listbox still comes with its own set of interface problems. Remember, the goal here is to make an interface that's not confusing for the user, not overwhelming for them, but is not restrictive either (no sense in slowing the user's work-flow down). Depending upon the default selection, the listbox induces users to interact with it. The problem with a listbox which has items the user must scroll to see, is that the user doesn't know what's off-screen, so they want to find out (because it might be a better option than what's currently selected). Popup menus don't have this issue when the currently selected item seems reasonable to the user. Because the information isn't displayed, they're not as tempted to discover what the "missing" information is. They're more likely to assume that the default is appropriate for their needs and move on. It's not until the default seems inappropriate that the user interacts with the popup menu to discover their other options.

I assert that for a certain-sized set of options, a popup menu is the most appropriate control to use. It does not detract from the overall dialog design by placing too much emphasis on the list of options (such as radio buttons might do). It still allows for simple user discovery, but it doesn't encourage the user to dwell on the options unnecessarily (such as a listbox might do). Finally, it doesn't overwhelm the user with options until they've already made the decision to interact with the element (such as both radio buttons and listboxes might do).

Before I move on, I also want to point out something about radio buttons: keyboard navigation with radio buttons is confusing on Windows and Linux. The way you usually navigate the UI is by using tab or shift+tab to move the focus between controls. However, radio buttons do not follow this standard. The group of radio buttons is considered one single entity, so you tab into the radio button group. Hitting tab again does not bring you to the next button, but instead brings you to the next control not in that group. In order to navigate between the buttons, you have to use the arrow keys. This is true with all the list controls (ListBox and PopupMenu included). However, with those controls, there's typically only one control involved from the user's perspective. So the user expectation is that hitting tab will bring them to the next control, not the next item in the list. But with a radio button, they are visually seperate controls, so a reasonable user expectation is that hitting tab will bring them to the next radio button. This is where the confusion lies.

Now that I've made my assertion, I want to talk a bit about when it is appropriate to use radio buttons and listboxes.

Radio buttons work great if there's only a few options (I usually say < 4 options) because they're not overwhelming to the user (since there's so few), and there's not enough of them to detract from the dialog's purpose. They provide the user with quick access to what choices they have, but still seem like a manageable number to users. A popup menu, on the other hand, would seem almost empty in many situations (as would a listbox).

Listboxes work great when there's enough information to almost fill them. I've found that the issues arise only if there's too little information in them (a listbox with only 1 or 2 rows looks strange and wastes space), or if there's too much information in them (the problem with the user wondering what's beyond their current visual options). Now, keep in mind, I'm talking about listboxes in the context of a single-selection list (not as data displays). When there's enough information to display to the user to fill the listbox, and the listbox doesn't contain a "bunch" of rows to it (I usually say 5-10 rows), then it can be a great choice to present information to the user. Since they can see all the options without scrolling, there's no issue of the user feeling the need to explore. The UI is still small enough that it's not obtrusive. And the choices are still there for the user -- but understand that this can be a curse too. It could also start to feel overwhelming to the user.

So those are my thoughts (as well as some facts) on the topic. Hopefully this clears up where I was coming from in my last UI discussion (and for the people whinging about the layout last time, hopefully this post is better for your eyes).

8 Comments

"With a marginal amount of effort, can have easy single-selection keyboard interaction by using the first letter of the row as a mnemonic."

On this topic, do you think we could get this functionality in the IDE? I would love to be able to select controls or project items without having to use the mouse.

Sure, feature request it.

Yah Aaron! Great post! Keep 'em coming!

Sorry for the offtopic posts. Here is the request: http://realsoftware.com/feedback/viewreport.php?reportid=ddtkrlcu

Here's a UI question for you (inspired by the "Heading out!" post):

When designing a user interface that tab panels, page panels or the like, what are the:
1) Proper methods of using them.
2) Proper methods of adding/removing controls to them. (As in, preventing the IDE from suddenly forgetting which panel controls are supposed to be on -- I've had that happen so many times!)
3) When it would be appropriate to use a specific type. (Like using a PagePanel with a page switching mechanism like TweakUI rather than a TabPanel.)
4) Other DOs and DON'Ts that you may know.

BTW, this was a great post! Keep up the marvelous work!

-BluJai

Popup menus: "Not all platforms allow quick user interaction with the keyboard by default (such as the Mac)."

I would contest that statement. While setting focus on a popup memu is disabled by default, you can certainly type to select. You can type the first few letters (depending on how fast you type); you are not limited to just one. And keyboard focusing/opening can be enabled.

Just my two cents :-)

@Asher -- that's the point though; the ability to select the control at all is disabled by default. So you can't rely on it being present on a user's machine (since they can turn it off entirely).

Anyway, the use of listboxes for action selection is rather rare on Mac. Stick to pop-up menus or radiobuttons on that platform, unless you have good reason to use a ListBox.

Great article. Thanks...

Leave a comment

Disclaimer

I'm currently an employee of REAL Software. My blog is mine. The opinions represented in this blog are mine as well and may not represent my employer's opinions. All original material is copyrighted and property of the author.

REALbasic® is a registered trademark of REAL Software, Inc. REAL SQL Server™ and Lingua™ are pending trademarks of REAL Software, Inc. All rights reserved.