In general, having choices is a great thing.

But often times, there are TooManyChoices.

If you go to a restaurant, and they ask questions about how specifically you want your dinner prepared, you might get annoyed.




TooManyChoices is similar to FeatureKarma.

This is one of the key lessons of HumaneInterface. Having only one way to do something (monotony) is good, because it promotes habit-forming.

::"The extra choice requires extra thinking, and the time saved by using an optimal interaction technique is often smaller than the time wasted on having to think instead of just moving ahead with a single interaction technique that is always used. It takes at least one second and often two seconds to decide between two possible interaction techniques which is why it is usually better not to offer users a choice." – Jakob Nielsen [1]

This seems long-winded. What is a short way of saying this?

some ways to avoid TooManyChoices

The Perl motto is "There's more than one way to do it." Divining how many more is left as an exercise to the reader.

The Paradox of Choice

The Paradox of Choice: Why More is Less book by Barry Schwartz

"A wider range of slightly inferior options, then, can make it harder to settle on one you’re happy with.""


"Restricting choices" or "reducing choices" (which is measurably good in some cases) sounds like "restricting freedom" (which is generally seen as bad).

MinimalistLaw claims that there can be (and often are) too many laws. That seems related, somehow.

So, yes, "restricting choices" sounds bad. "Making choices at the right time" sounds better. Some decisions need to be made by users; others by distributors or administrators; others by designers.

For example: automotive engineers build in a lot of choices for drivers. Drivers want to be able to adjust how far their seat is from the steering wheel, the angle of the rear-view mirror, the temperature in the car, the radio station, whether the window is open or closed. So engineers have to build in features to let us make these changes in the car environment whenever we use it.

But automotive engineers don't make detachable steering wheels and pedals that can be installed in any seat in the car; the driver's controls are always in the same seat (at least within one country!). Drivers don't need to make that decision every time they drive ("Hmmm… should I drive from the back seat or the roof this time?"). That decision is already made by the engineers (and local governments). We can't change the color of the car (a decision we made a purchase time) or how many wheels it has (a decision made by… uh… I'm not sure).

A car that was fully configurable in all these ways would be extremely costly, without giving any tangible benefit to drivers. It'd also be less reliable (since complexity introduces bugs). As drivers, we let engineers make design decisions for us because we don't want to have to decide over and over ourselves.

Designers of all kinds (software, hardware, information systems, what have you) have to have the courage to know what they should decide and what they should leave up to their users. TooManyChoices is not that much better than NoChoicesAtAll.

JefRaskin would claim that NoChoicesAtAll is better, because users are usually not as good designers as professional designers are. From this follows that 1. you need good or professional designers, and 2. if your design requires a choice to adapt to your users, then maybe that is a design bug.

Example: You designed a mail client with two interfaces, one expert and one newbie interface. You just need the user to indicate what type of interface he wants, and off you go. The choice is unavoidable you say? Jeff Raskin would answer that building two different interfaces is a design bug! Instead you should build an interface that is simple but powerful, satisfying both newbies and experts. Of course this is harder, but that's why you have good designers, right?

Not only is it a design bug, but it's opening up the door to a ton more software bugs. You've got double the interfaces, so now you've got double the complexity and double the source you have to debug and keep clean.

Maybe sometimes designers build in TooManyChoices because they're mussing around with things that aren't their business in the first place.

I like EricRaymond's story about building fetchmail (a POP3 client) in The Cathedral and the Bazaar. One of his aha! moments was realizing that, instead of writing to N different kind of mailbox files, fetchmail should simply re-post POP3 mail to the local SMTP server. Simpler and easier. Fewer choices, but more power to the user.

Another car design example: baby seats. People with young children need special seats for those kids. But if car designers were to make that choice, they'd have to build cars with two baby seats, one baby seat, one infant seat and one older child seat, expandable children's seats, etc. etc. But they don't do this: people just go buy plug-in car seats for their kids for the right time of their life. Guessing how many kids will be in a car or how big they are isn't the job of the auto engineers – people can do all that themselves.

This is an awesome idea, and really important for us right now in the software world, especially.

The page felt a little, I don't know… edgy? I've tried to soften it up a little bit.

:instead of writing to N different kind of mailbox files, fetchmail should simply re-post POP3 mail to the local SMTP server. Simpler and easier. Fewer choices, but more power to the user.

Actually, while I think that was the right design choice, because it makes the architecture more modular, I don't think it made things "simpler and easier" at all, at least not for the user. When I first came to GNU/Linux I was very confused by the mail-delivery system. On my old computer, I understood that Microsoft Outlook downloaded my email from my ISP's server and stored it in a file. On my new system, it was hard for me to understand why my own computer was running this mail daemon called "exim", in addition to "fetchmail" which I called to get my mail, and "mutt", which I ran to read the mail. If "fetchmail" downloaded my mail from the external server, I thought, what else is there left to do?

So, I thought exim was some thing that Debian pre-installed in case you wanted to serve mail to others, like an ISP does. This was very confusing for me when I took my computer to my parent's house for christmas and had to reconfigure it to use a different ISP's outgoing SMTP server in order to send email. I looked and I looked, but I could not find the config option in either "fetchmail" or "mutt" which held the outgoing SMTP server.

To this day, the powerful abstract generality of exim makes it a labor-intensive task for me to figure out how to reconfigure it to do something new or to fix some problem.

:MinimalistLaw claims that there can be (and often are) too many laws. That seems related, somehow.

Here's one way they are related.

If one had infinite time (and patience!), it would not matter if one had to choose between 500 kinds of jam upon each trip to the supermarket, or if one had to read through 400 pages of legal briefs in order to determine one's rights in a small dispute over a telephone bill.

However, the time limitation means that we do not have time to educate ourselves about a lot of choices, or about a lot of laws.

So, too many choices or too many laws are both instances of InformationOverload. The user does not have time to absorb all of the relevant information.

The most powerful antidote to InformationOverload is simplicity. Simplify software so that it is just as powerful, but requires less choice. And remove choices (& powers) which aren't worth it. Simplify laws so that they say the same thing, but in less words. And remove laws which aren't necessary.

Are the second and third ways to avoid TooManyChoices supposed to contradict each other? :P

Now that you point it out, I see the contradiction. There is a wiki page at ____[FIXME]___ on heuristics that seem to conflict. "Look before you leap" vs. "He who hesitates is lost", etc. – DavidCary




Define external redirect: BigOAnalysisOfInformationOrganization

EditNearLinks: FeatureKarma FreeLinks CamelCase EricRaymond JefRaskin HumaneInterface DissuadeReputation