The tyranny of 1 or N

UIs support working with one thing at a time, or with a potentially infinite list of N things, but rarely for dealing with a small fixed number of things. This is too bad—there are some cases where supporting a small fixed set leads to a simpler user experience.

Consider the typical example of a list in this Windows XP Control Panel:

Let's see... How many modems do you think the typical PC has? I have no idea, but I'm guessing the numbers are something like: 70% of PCs have no modem, 29% have 1 modem, and 1% have a number of modems between 2 and 4.

You couldn't guess this from the UI above, though. The UI makes it look like it's common for a PC to have dozens of modems. The list box alone is tall enough to show about 13 modems comfortably before it needs to scroll. Who has 13 modems?

The product development process that produces a UI like the one usually goes like this. A designer builds a UI to edit settings for one modem, since that's the common case. This UI includes a collection of edit controls like dropdown lists for things like modem speed, duplex handing, etc. A tester on the team complains because they've got a machine that has two modems, so the designer is told they need to support two modems. The designer discusses this with the developer, who says that they don't want to have duplicate the whole set of edit controls to support settings for two modems: copying the controls is a pain, and besides, the code gets ugly. To a developer, the only numbers that make sense for UIs are 1 and N. If you don't want a UI to edit one thing, then put in a list box that lets you edit an essentially infinite number of things. You've not only solved the problem of the person with two modems, you've covered every conceivable configuration ever. Problem solved.

This is weak thinking. The team may discover a significant new problem on their hands: the vast majority of users who come to this UI to set up their one and only modem must now first go through an extra, non-obvious step. The user comes into the dialog to find a big empty white rectangle, with most of the controls disabled, and it's not clear at all that the thing they need to do is click the "Add..." button.

It takes guts to hardcode a UI to deal with a fixed number of things that covers 99% of your scenarios. One group of designers who consistently do this right are people who design cellphones. List management on a cellphone is a pain, so whenever they can, the designers give you a fixed list of things. My cellphone lets me switch between different "profiles" by selecting from a fixed list of exactly eight items: normal, silent, meeting, outdoor, automatic, headset, car, speakerphone. I can't add another profile, but that's fine—I can't imagine what else I'd need to create another profile for, and in any event I could always repurpose an existing profiles that I don't use.

There are certainly many cases when a list box is appropriate, but if virtually all of your users will only need to work with a small handful of things, consider optimizing the UI for a small fixed set.

Comments

[Joe Hughes]

Great observation, Jan--you've nailed the problem and the engineering mindset that leads to it.

[Tom Z.]

I don't agree. Why lock out even 1% of users from being able to use your software by creating a 99% UI? Workarounds are very ugly at best; not possible in many cases.

How do you explain the decision to customers who call to say this is a problem for them? That they can't do what they want because the UI is optimized for the 99% of cases, and therefore, that customer's case is not possible?

Having guts is one thing, but this would not be a smart decision, IMHO.

At a minimum, there would need to be an additional "Advanced" UI to handle the 'n' case, but I don't think the additional complexity is justified.

[AIM48]

I have seen Telephony Servers with up to 20 "Virtual" modems that all show up as indivual listings in this box. While a system like that has better modem admin tools - You still require this space in the listbox.

[David]

I think a good way to handle such a situation is to have a list that can host N items, but instead of using the Listbox with one line per item, use much more vertical space per item and put controls for the main properties on there right away. Every item can also have a button "Advanced..." that opens up another dialog for the obscure situations where you need to change one of the rare settings (which most users probably never use anyways).

[Bleh]

Thank god you're not in charge of anything important... It's people like you who made Windows XP the piece of junk that it is. Please Microsoft, go back to the mentality that brought us Windows 2000.

[Steve Ball]

Bleh: pretty lame anonymous comment. It's useless feedback like yours that is an ironic example of that which you criticize: you offer nothing actionable or insightful. I can't even disagree with what you say because it is a meaningless (negative) opinion, but I can certainly disagree with your rude hostility.

[Steve Ball]

Which reminds, me; I did come to these comments for a reason. The idea that it is possible to design UI/UX in a way that simultaneously anticipates the needs of and serves all possible users in a world where you may easily have 10, 1000, or 1M customers over a 1, 5, or 10 year period, is unrealistic. I really love this site in that it gently expresses the non-trivial challenges that exist in UX design with real examples rather than simply spouting subjective theories about design. Great job, Jan.

[Peter Arrenbrecht]

I agree with Dave. HTML makes this easy, Win32 and WinForms et al do not. Avalon might be the thing that is going to help a great deal here. (We wrote our own UI layout and replication framework for just this reason.)