Defaults are a new phenomenon made possible and necessary with the advent of modern flexible technology. Now people rarely change defaults and Kevin Kelly in Triumph of the Default makes this excellent observation.
Therefore the privilege of establishing what value the default is set at is an act of power and influence. Defaults are a tool not only for individuals to tame choices, but for systems designers — those who set the presets — to steer the system. The architecture of these choices can profoundly shape the culture of that system's use. Even the sequences of defaults and choices make a difference too.
This last idea — that even subtle differences in the options presented to a user can unconsciously influence their ultimate decision is also made in this interesting TED talk on are we in control of our own decisions.

Too many options

Before I go on to analyze some good and bad defaults, a very important point to be made is that system designers tend to add too many settings in the first place. Rather than deciding on or auto-detecting the most appropriate course of action, they push the choice to the user, sometimes with the mistaken idea that users would prefer to make the decision. This is very bad as it increases complexity and makes features less discoverable. Note also that it's inadvisable to prompt to aid in the discovery of new features. Seth Godin also make the point regarding the interface clutter, and how it desensitizes users to the important functions.

Look at the tar man page for example. This shows an opaque mess of options accreted over the years, many of which are esoteric at best and redundant at worst. Consider the most common usage of extracting a compressed archive. Following instructions in the man page one would tar -xzf foo.tar.gz or tar -xjf foo.tar.bz2 or more generally tar --use-compress-program=xz -xf foo.tar.xz. But why have these compression options at all when generally one can gzip -dc foo.tar.gz | tar -x? Even if one does want to have tar call the compression programs internally, why can't it auto-detect the supported types? In fact it does have this undocumented feature since tar 1.15 (2004). I.E. one can do tar -xf foo.tar.gz or tar -xf foo.tar.bz2. However the detection is based on the file name extension and so tar -x < foo.tar.gz will not work unfortunately.

What a mess. Unfortunately once an option is released it's very difficult retract as it could already be used by users. Thus one typically needs years of documentation changes and deprecation warnings before removing a badly thought out option.

Good defaults

An example of where well chosen defaults have made a measurable difference is with the firefox browser, where they have lead to a simpler product for users, and thus a more successful product. Firefox originally started out as the seamonkey suite but used the old netscape interface and settings. I used to change many defaults on this and even switched the theme to pinball which is something I never tend to worry about. Then as the standalone phoenix/firebird browser started to emerge in 2002/2003 there was more emphasis on the interface branding resulting in the debut of the firefox browser in 2004 which has really taken off. When one starts firefox for the first time, you're presented with sensible default prompts with answers defaulting to not prompt you again and this all gives you a good feeling for a well thought out product. I have needed to tweak a few settings for firefox but with each release it gets even better.

Taking another specific example where I think things were done correctly, i.e. where an option could have been added but wasn't, is in the linux `cal` utility. This command displays a calendar on the terminal, and was updated at the start of 2005 to highlight the current date. It was suggested that an option be added to turn this on. However that wouldn't have been nearly as discoverable for users, compared to assuming they would always want this. If one is further processing the output from cal, the highlighting is turned off automatically, which also allows the tiny number of users who don't want this functionality to do cal | cat.

Bad defaults

There are no end to examples of bad defaults unfortunately, and here I show a few examples from my linux system.

--color=auto

Much like the `cal` highlighting mentioned above, colour should be enabled by default if the terminal supports it. Note even the ls --color option itself has the wrong default, as it should be --color=auto like grep rather than --color=always. Labouring the reasons again for why it would be better to enable this by default:

ssh

I've mentioned before openssh's apparent lack of consideration of interface. Consider the ssh -X option to enable X forwarding. This could also be known as ssh --enable-X-forwarding-but-break-things-in-obscure-ways. ssh -X used to work but now one needs the new -Y option to get it to actually work. Also ssh needs a new "no encryption" option to enable efficient transfer on trusted networks.

vim

vim is quite unusable by default in the name of backwards compatibility. Some fixes to wrong defaults from my .vimrc:

bash

I need to have export HISTCONTROL=ignoreboth in my .bashrc so that the history is not cluttered with often repeated commands. Also related to the history navigation, I bind the up and down arrows to the history-search-forward function, to search the history for commands starting with the already typed text.

miscellaneous

© Jul 7 2009