thoughts on usability, coding and other nerd topics

Posts tagged with “bare bones software”


Preferences Considered Harmful

Every programmer and user interface designer eventually comes to this point: You can’t decide how a specific part of your user interface should behave. It’s easy, of course. Just make it a preference, and everyone will be happy.

After a few years, you will end up with a preference window looking like this:

BBEdit Preferences Window

BBEdit has so many preferences that Bare Bones Software actually included a full-featured search function within the preferences window. At one point during BBEdit’s existence, somebody must have been annoyed with BBEdit’s default window stacking algorithm and requested that it be made a preference. Here it is:

BBEdit's window stacking setting

BBEdit actually allows you to select the window stacking algorithm. I’m sure somebody, somewhere absolutely needed that feature, but by implementing it, Bare Bones Software forced everyone else to also consider that preference when trying to change a setting.

Now, I want to make it clear that I don’t fault Bare Bones Software for this. Their audience is a diverse set of power users. Programmers, writers, sysadmins and other high-end Mac users all use BBEdit for vastly different tasks, which is why BBEdit has ended up with a huge set of preferences.

However, unless you’re working for Bare Bones Software, your product probably is no BBEdit.

For most applications, the target audience consists of — or at least includes — casual users. These users easily get confused by preferences, and they can become frustrated when they attempt to use a familiar application where somebody has changed preferences.

For this reason, it’s best to avoid preferences.

Configurations aren’t Preferences

Not every item you find in an application’s preference window actually is a preference. Before talking more about how you can avoid preferences, I want to define what I mean by the word “preference.” I find it useful to distinguish between configurations and preferences.

Configurations

When a given feature of your computer needs you to change settings to make it work, this is a configuration. For example, most entries in “System Preferences” aren’t preferences at all. You don’t “prefer” to turn on Screen Sharing; turning on and setting up Screen Sharing is part of your system’s configuration. You don’t “prefer” that only some users have access to your computer’s screen; you configure your system so only some users can access it:

The Sharing Preference Pane

Preferences

Changing a preference does not change the functionality of an appliation. It only changes the look or (superficially) the behaviour of an application. Often, preferences are introduced to appease a specific group of users. For example, when Apple introduced Mac OS X, a lot of preferences were introduced to make OS X behave more like Mac OS 9.

On NeXT systems, both scroll bar arrows were at the same end of each scroll bar, while on Mac OS 9 and earlier, they were on opposite ends. Instead of deciding on one behaviour, Apple simply made it a preference:

Scroll arrows preference

Additionally, Apple added a hidden preference for those who wanted both arrows on both ends.

Why preferences are bad

There are several reasons why cluttering the settings windows with unnecessary preferences is bad.

First of all, it is confusing to people who have legitimate reasons for changing settings. If you want to find out how to change your Dock size, you don’t want to work your way through a list of preferences which includes useless settings about how windows look while they minimize.

Often, applications’ preference windows are cluttered and confusing to the point where it becomes unclear whether something can’t be changed, or whether you simply missed the option in the flood of checkboxes.

Second, it makes applications inconsistent. If a user is used to a system where the Finder’s “Always open folders in a new window” setting is enabled, he can easily become confused and frustrated on systems where this is disabled. If a user is used to getting a warning before emptying the trash, he could easily inadvertently delete files on a system where that warning is turned off. And if he is used to a system where the Finder opens blank DVDs, he could quickly get stumped when a system instead opens iTunes.

Third, it makes reproducing errors harder. The more preferences there are, the more code paths you generate. Trying to reproduce user issues can quickly become a nightmare if you first have to reproduce specific sets of preferences.

How to avoid preferences

So, if preferences cause so many issues, how can you avoid them?

Say no to users

Sometimes, it’s better to lose a few users than to endanger the application’s overall health. Perhaps having pink windows simply isn’t in the application’s best interest, and if not having pink windows means having a few customers less, so be it.

Decide on the best behaviour and run with it

If at all possible, get rid of preferences and go with the most desirable behaviour instead. Often, interface guidelines state how an application should behave. Adhering to the standards not only helps you get rid of preferences, but also helps you be consistent with other applications, which makes your application behave in a manner predictable to your users. If the interface guidelines don’t specify how your application should behave, an ad-hoc usability test should help you decide which behaviour is preferable. Create versions of your application with both behaviour and let some users who have never seen the specific function use the app while you look over their shoulders. Which behaviour do they grasp more easily?

For most preferences, there is one option which works better. Find out which this is, and make it the standard behaviour.

Remember the application’s state

Often, you can avoid preferences by keeping track of what the user is doing. Instead of letting the user specify default data, remember the most recent actual data he generated. If the user switches to list view to see his “things,” open in list view by default. If the user opens a window and turns the toolbar off, remember that for the next window he opens. If the user sorts list entries by date, remember that the next time he opens the application. Always remember window size and position, and when the user has to enter data, try to provide reasonable default data.

Be careful not to be too clever, though. Adapting the UI to statistical analysis of user behaviour typically leads to a frustrating user experience, because the user interface becomes non-deterministic from the user’s point of view. Make sure the rules used are always obvious to the user.

If you can’t avoid preferences

There are cases where you simply can’t avoid preferences. If this occurs, make sure you spend time on finding reasonable defaults, and on labeling them in a way which is obvious to users.

What about an “Advanced” section?

Some applications try to de-clutter preferences by partitioning them into a “regular” and an “advanced” section. I would avoid this because the difference between normal preferences and “advanced” preferences is arbitrary. If you’re looking for a specific setting, having an “advanced” section means you have to hunt through additional screens.

May 18th, 2008 / Tags: prefernces, bbedit, bare bones software, apple, finder, usability / Trackback