Tom Chi  

Here are your options….

January 14th, 2006 by Tom Chi :: see related comic

So let’s say you have an Outlook Add-in that needs to be disabled. How to do it? Simple… Tools > Options > Other Tab > advanced options button > add-in manager > uncheck the appropriate add-in > click “OK” - Done. That, is unless it was a COM Add-in, or a custom form… in which case you do a different thing. At this point you might start wondering how such a monstrosity was ever designed.

Well a funny thing happened on the way toward shipping the product. Somewhere along the line, two people disagreed. One said feature X should work like this, and the other said it should work like that. A developer raised his/her hand and said: “how about putting it in tools > options?”. The parties looked at each other:

A: “So how many people will this effect?”
B: “Probably less than 10% of our base…”
A: “Heck, ok then - Tools Options.”

If it didn’t happen that way, then it might have happened this way:

Developer: “I know people who would want this feature to work either way… I’ll just put in an option. That’s the most democratic approach.”

Oh and lastly:

Product Support: “If you change that option, customers will have to retrain their staff to go through those other dialogs - let’s just keep it like that for one more release.”

You can see how this might lead your options dialog to distress. Add on top of all this, that the fundamental interaction of an options dialog makes it difficult to understand how your adjustments will be represented… and over time you’ll be left with a user experience disaster.

To avoid all this, you must simply:

1. Do fewer features.
2. Place options and settings in context (many people do not right-click either, but at least when the option is adjusted, you know what will be affected)
3. Pick a right way of doing things - don’t leave it all to “user preference.” Sometimes cutting off one pathway hurts less than providing an option, because removing that path means one less thing for *everyone* to understand.

9 Responses to “Here are your options….”
Moi wrote:

You know that it is marketing that decide to add new features and not the developers, right?

If I had my way I would have a bunch of applications which each do one thing well that I could link together somehow. *cough* Like Unix. *cough*

Bob Salmon wrote:

A factor to consider in this is how tightly must the product fit into its surroundings, e.g. the business processes of the customer?

If it’s a home finance manager then deciding that people must do X before Y (and not giving them the option of having Y before X) might be annoying to the user but, other than possible market share for future buying of software, there’s no money involved.

If it’s a customer service rep system, every second counts, and if this particular installation never needs Y then forcing them to click Cancel every time on the screen they don’t need could burn time and hence money.

You bump into the shrink wrap vs. custom continuum - eventually you say: OK if you want that level of flexibility I’ll give you an API and you can build your own business logic and your own work flow and GUI on top of that and your offering becomes a combination of product and services (custom code writing / support).

On the question of adding features to existing products, our policy is that everything new must be off by default (wherever possible). Existing customers already have to take a lot of time and money (months and more money than I care to mention) migrating to new releases. This is just to check for regression in existing features and checking out the subset of new features that they want. Forcing them to test all the new features they don’t want would make us very unpopular. (This is on top of the retraining costs you mention.)

I don’t think there’s a definite answer other than: It depends.

Michalis Kamburelis wrote:

I just have to place here a link to Havoc Pennington’s well known article “Free software and good user interfaces”, []. One of his major points is exactly that “too many preferences are bad”. This is quite a must-read for everyone interested in free software UI (and especially GNOME).

Reed wrote:

I work on a product that is internally very very complex, and has hundreds of configuration options. Each user may need to modify a slightly different subset of these options to make the product work in their environment (physical environment, so the possabilities are literally limitless).

Instead of a hierarchy of tabs and dialog boxes, we have one configuration window. The configuration parameters are sorted into sections, and you choose a section from a list on the side. Then all of the parameters are displayed in a big table, with similar parameters grouped together.

Finally, the user selects a priority: Required, Typical and Advanced which filters which parameters are displayed. Required parameters are required to be set before the product functions correctly. There are only a few of these. Typical parameters are things that users may want to adjust to improve or customize behavior. Advanced are all the details that a few users may need to change for certain unusual circumstances, or if they want to really tweak performance to the max — or accidentally screw it up completely.

Finally, the user interface only displays what is enabled on the product, rather than having a zillion buttons that don’t actually do anything. This lets you have as simple a user interface as neccesary.

We don’t deny that having hundreds of parameters is daunting, but it’s a complex system, and it would be foolish to hide that complexity completely from the user (”dumb it down”) since that would ruin the benefits of it. But we try to customize the UI to the user’s level of expertise and needs.

Reed wrote:

Michalis, I’ve argued in Gnome Bugzilla comments about adding options. I like the fact that they threw out a lot of needless complexity moving from Gnome 1 to Gnome 2. But Sometimes they chose to make accessibly to the user only a subset of possible logical options. For example, There are 7 things you can do to a window in Metacity, but only 6 of them are displayed in a window’s menu, and there are only 2 choices for what happens when you double click on the titlebar. You either make some things options or you don’t, but choosing inconsistently from them in different places in the system is only better than the Microsoft approach in XP (to make a dozen different mazelike pathways to access the same controls).

Sherman Dorn wrote:

I don’t mind the trail, as long as potentially-clunky things come default DISabled. I will never forgive laptop manufacturers for setting tap-click as enabled by default.

White Rabbit wrote:

Two words - Occam’s Razor

* slice *

Jon wrote:

Why 37 signals is the new pink.

And pink is the new black.

And black is good.

Stephen wrote:

The flipside to the GNOME argument was put succinctly, if controversially, by Linus Torvalds (, note coarse language warning):


That’s not what I’m talking about at all.

When user interfaces means that something CANNOT BE DONE, it’s not about
“usable design” any more. At that point, it’s about UNusable design.

Any Gnome people who argue that it’s about “usability” have their heads up
their asses so far that it’s not funny. I’ve argued with them about this
before, and I know others have too, and mostly given up.

“Usability” is an issue only if you can do something at all. But if you
can’t do the thing at all, it’s pointless to talk about usability: the
thing is BY DEFINITION not usable if it cannot be used for a specific

Then a person that claims that it’s usable for something else is a F&$*ING

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?