Unquiet

In [The Problem with Preferences][1], Jason Fried writes:

[1]: http://37signals.com/svn/archives2/getting_real_the_problem_with_preferences_interface_design_and_the_customer_experience.php

> At 37signals we’re pretty anti-preference/setting. When we Get Real we try to make informed decisions for the people who use our products so they don’t have to think about preferences or settings or adjustments — they can just use the product and know that the people who built it already thought about the best ways to design it, use it, and view it.

and:

> … be careful when you add preferences. Preferences aren’t free. Each one adds a little more uncertainty to the customer experience you are selling. The goal is to find the balance that best suits you and your customers, but don’t always assume more customer control is the better choice.

I agree with the idea of applying Occam’s Razor to preferences. Ideally, an application should require minimal configuration at the beginning; Usable systems, for the most part, _feel right_ to the user, encouraging a short (but not necessarily shallow) learning curve. However, understanding the difference between __input__ and __preferences__ helps define what you absolutely need to add to your application.

__Input__ is information that’s required for the proper operation of your software. For many web-based applications, this includes such information as login, password and email address. For an invoicing application, each invoice requires input such as description of work or service, client and cost. These are not preferences; as input they are intrinsic to the function of the application.

__Preferences__, on the other hand, affect how the application works on a less-specific level. Color schemes, custom logos and how many posts per page, the like. Any preferences required by the application to function should have sensible defaults preprogrammed. Why should the user be required to change the operation of software they’ve never used?

To me, this is the major point of Jason’s post: don’t toss preferences into software just because you can. Make sure each and every option needs to exist, and that each preference provides meaningful change in operation.

Having said that, I don’t agree with the secondary sentiment of the article, which deals with controlling the path of the user in an effort to create an ideal environment. Here’s why:

### Control is an illusion

_Your users are going to use your software in ways you’ve never imagined,_ especially now that technologies like RSS and Atom become increasingly prevalent. RSS feeds branched out from blog and news items; now they carry to-do items, [Backpack][2] updates, del.icio.us bookmarks, audio and video content, photos, etc., etc., etc. Savvy users tend to demand some method of interoperability among their tools, either through RSS/Atom or other APIs, and that interaction confounds __any__ sense of control you have over how your software will be used.

[2]: http://backpackit.com/

In addition, the power users tend to be the vocal, passionate segment of your customer base. They’ll blog about their experiences, share their creations with friends and colleagues, and speak about you with a passion that _matches the creativity possible with your software._ Most of your customers will use the software exactly as intended, ignoring its most powerful and interesting uses, but the ones that push the envelope will be the ones that drive your business forward or backward, specifically depending on how much effort you spend trying to control what others can do.

[Apple][3] provides a prime example: exerting incredible control over the production of their computers and the development of their software, they build a system with a short but deep learning curve. After purchase, however, Apple recognizes that the system is no longer theirs: the user chooses its path from purchase on. Apple succeeds at this not because of a wealth of user preferences that can be changed, but rather because neither the system nor Apple itself attempt to control the creativity of the end-user.

[3]: http://www.apple.com/

That’s how web tools should be developed. Exert tight control during development, avoid feature creep, eschew unnecessary preferences, and open up your application to creativity: use open formats, provide APIs, export into standardized formats…

Still concerned about the user experience with all that freedom? That’s where good testing practices come in. Make sure all your known uses have tests, and when one of your customers discovers a new use, write a test for it - the new use becomes a ‘feature’! If, while trying to do something new and unique, a customer discovers a bug, see if you can’t fix it and enable the customer’s creativity. Again, it becomes _not a bug, but a feature_.

In an age of user-side customizability (ala Firefox’s Greasemonkey), web service mash-ups, and derivative services (see the wealth of tools that sprang up around del.icio.us’ bookmarking service), control is little more than an illusion once the software meets its user. You can’t dictate how and for what people will use the tools you write, and you don’t really want to.

So go ahead: be anti-preferences, but please don’t be anti-creativity!