The About:Config School of Configuration Settings

May
28
2007

I've been reading the Getting Real book here and there. There's some good advice in there as well as some stuff that works well in *their* situation: building web-based tools/services for the open market. Like all business advice, it works for a subset of all available business situations. That both means that you can't treat their advice as universally applicable and you can't treat it as worthless.

Their article on eliminating preferences is what prompted me to write. See, they tied together the ideas of user preferences and user *editable* preferences. The distinction is important because I think that lots of people hear the advice to "Just make a decision." and hard-code every setting in an application-wide approach that hamstrings them later.

The Mozilla apps take an "in between" approach that I think is a happy medium. If you type "about:config" into the Firefox address bar, you'll be presented with a huge list of configuration options, many of which are *not* available directly through the user preferences screens. Any that are in bold have been changed by you (or something on your behalf).

The rest represent the exact kinds of decisions that 37 Signals is talking about. They picked a value that should apply for most folks. However, instead of making it a forced value for ALL installations of Firefox, they put it into the users configuration file. They didn't expose it via a preference screen. That lets people who want to keep things simple do exactly that. However, it means that those whose needs don't fit inside the neat box get at the settings they want.

As a general way to implement this, I suggest making *everything* that power users might want to change into something configurable. Put this in a place where someone who knows what they're doing could get to it. For desktop or console apps that could mean a text file, for web apps, a URL that provides a basic editing grid, etc. It doesn't even need to be visible from the interface. Then, separately, make decisions on defaults and decide the few things that the users in the middle of the bell curve will be able to change and actually create config options in the interface for those.

This compromise lets you implement the 37 Signals advice, while letting the people who are going to do interesting things with your application do just that. I love pushing software a bit, and the first thing I look for is a config file and an API when considering adopting a new technology.

 

Comments on this post

Feedback is always welcome. Read some from other folks or leave your own below. Just keep things civil and remember that what you post lives on in public. Forever.

Thanks,
J

One Response to “The About:Config School of Configuration Settings”

  1. Asa Dotzler Says:

    You said, "As a general way to implement this, I suggest making *everything* that power users might want to change into something configurable."

    This works well for some things. Where building in that knob costs performance or otherwise worsens the application for the people who won't ever touch the knob, it doesn't work as well.

    The same goes for what is more commonly thought of as "features" (as distinct from "knobs" for features that you're talking about.) It could be argued that the Firefox feature set should include *everything* that a power user might want, perhaps just not turned on by default. Here again, and more obviously, we see that there are cases where the features cost in performance or otherwise worsening of the user experience suggests it's not always a good idea.

    Other areas to consider besides performance (and in there I include footprint — both for the download size, and disk and memory usage) are security, stability, and web compatibility. The more combinations and permutations that are available, even to the "power users", the more testing is required to ensure that all of those combinations and permutations don't lead to instability, security or privacy vulnerabilities, or broken web compatibility.

    We're blessed at Mozilla with a lot of volunteer talent and we have worked hard to build a large and passionate testing community, but there is no free lunch and every added feature, including preferences, has a cost against the baseline feature/prefs set.

    All of that being said, I think there's a good case for *many* features to be tweakable via something like about:config and I don't consider it very different from the "advanced options" found in many other applications.

Leave Your Own Comment

By submitting a comment, you agree to license it under the terms of the Creative Commons Attribution license.

People who post comments get the added benefit of visiting the site without advertising.

© 2003-2008 J Wynia. All original content is licensed under the terms of the Creative Commons Attribution license unless otherwise noted. Content from other sources is licensed under its original terms.