I Would Prefer Not to Set Preferences

I would prefer not to.

Everybody likes preferences, right? Maybe not. Maybe some people would prefer not to have to deal with it.

Apple users, for example, are given a fraction of the number of preference-setting options that Windows users get. In OSX, for example, you can choose several different ways for the dock to operate — but under Windows there are three dozen settings having to do with how things look when you click the Start button.

Customizing your workspace has always been one of the hallmarks of Windows. Do you want to show or hide your file extensions? Would you prefer to use the old Win 2000 GUI instead of the latest whiz-bang UI? Want to put your taskbar on the side of the screen instead of the bottom? Hide the Recycling bin? Control the horizontal and vertical distances, in pixels, between the icons on your desktop? All of these options, and thousands more, are available to Windows users. For many, these customization options are essential to making their workspace usable. (It’s almost like these options exist solely to allow users to fix Windows’ usability flaws.)

Apple, on the other hand (and perhaps surprisingly given their hippie reputation), is heavy-handed about their preferences. More often than not, Apple simply decides what is best for you, and if you want something else, well, tough luck.

Of course, many will argue that obscure features can be valuable, too — Einstein’s twist on Occam’s razor is worth remembering before cutting away features willy-nilly: “Make everything as simple as possible, but not simpler”. A convincing argument, however, in favor of limiting preferences as a core design philosophy is Havoc Pennington’s classic article “Free software and good user interfaces“, which contends that:

• Too many preferences means you can’t find any of them.
• Preferences really substantively damage QA and testing.
• Preferences make integration and good UI difficult.
• Preferences keep people from fixing real bugs.
• Preferences can confuse many users.

Interestingly, the first four points are almost all about development costs, not about end-user usefulness or usability. But the last one says plainly that more prefs can lead to more frustration.

I had a great preferences odyssey just yesterday that illustrates the last point perfectly.

My Preferences Odyssey

Since my primary work machine is a desktop workstation, I frequently work on one of Behavior’s “floater” laptops for business travel and on-site client meetings. The laptop I most often use has a touchpad pointer interface. Unfortunately, I have a tendency to accidentally contact the touchpad with my fingers while typing, causing me to overwrite entire paragraphs without even knowing it.

It finally dawned on me that maybe there was a system preference I could use to prevent this from happening. Sure enough, there was. And thus my odyssey begins.

First, I had to go to the “Advanced” tab under the Mouse Control Panel. Then, in a dramatic touch of déjà vu, you go to the “Advanced Settings” under the “Advanced” tab.

Then, you go to the “Detailed settings for touch pad operation”. This is the third time in a row where I’ve had to decide that my user needs were so advanced and esoteric that I need a special new interface to even consider them.

Here I have to click “Tapping Settings” to control this one particular aspect of touching the pad.

Finally, I have entered the inner sanctum. Here at last is a checkbox allowing me to indicate that I don’t want the touchpad to register inputs while I am typing.

The default for this setting is the unchecked position, presumably to support those power users who like to type and mouse around at almost exactly the same time.

It’s comical to imagine this extraordinary power user, someone who types characters all over the page at random — one second they’re typing a lower case “h” in the lower right quadrant of the screen, but a moment later they’re typing an asterisk over in the upper left quadrant . Or maybe they have several Word documents open simultaneously, and like a chess master playing six matches at the same time, our power user is writing a novel in one window, an email in another, some HTML code in another, and a blog post in yet another, juggling between these different activates ever couple of seconds.

The slider to determine the timing is a hilarious added touch. I suppose this is to permit the aforementioned type of power user to adjust the timing based on how skilled they are at the arcane art of typing and mousing at virtually the same time.

It’s painfully obvious that this entire functionality, which is actually a clever idea at its core, would be best implemented as a permanent and invisible feature that was always actively protecting the user from accidentally moving their cursor to another part of the screen when it’s clear that they are busy typing something. The details are trivial: the designers should have simply tested the device settings internally for a few hours, determining an ideal timing delay that works for most users, and then leaving that delay set in stone.

In fact, I’ll bet this is exactly what Apple does.