In Open Source, Learn to Decide

Dave Winer tweeted a photo of a weird, verbose, and confusing Android options screen. I love Android, but like most open source projects, it falls victim to the proliferation of options, rather than making decisions for its users.

When explaining this to developers at conferences, I generally mention the preference panels in Adium, a Mac OS X chat client. It practically has an Advanced tab for the Advanced tab. Stuff everywhere. Problem is, when there are too many options, your users can’t find any of them.

Open source doesn’t need to be this bad. One of the tenets of the WordPress philosophy is Decisions, Not Options:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

Buried in the annals of WordPress, a release philosophy document was heavily inspired by the writings of GNOME contributor Havoc Pennington. On preferences, he wrote (nearly 10 years ago) —

It turns out that preferences have a cost. Of course, some preferences also have important benefits – and can be crucial interface features. But each one has a price, and you have to carefully consider its value. Many users and developers don’t understand this, and end up with a lot of cost and little value for their preferences dollar.

  • 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.
  • The point of a good program is to do something specific and do it well.
  • Preferences keep people from fixing real bugs.
  • Preferences can confuse many users.

I find that if you’re hard-core disciplined about having good defaults that Just Work instead of lazily adding preferences, that naturally leads the overall UI in the right direction. Issues come up via bugzilla or mailing lists or user testing, and you fix them in some way other than adding a preference, and this means you have to think about the right UI and the right way to fix problems. Basically, using preferences as a band-aid is the root of much UI evil.

WordPress is known for its simplicity and usability, but I can still think of a half-dozen options I wouldn’t hesitate to remove under the right circumstances. Many WordPress plugins subject their users to too many options. Don’t add settings screens simply because you know how.

Challenge yourself. Learn to decide.

Published by

Andrew Nacin

Lead developer of WordPress, living in Washington, D.C. Follow me on Twitter.

44 thoughts on “In Open Source, Learn to Decide”

  1. It is not that simple to me.

    Sure, widely adopted software like WordPress can make decisions for their userbase. Unhappy users will deal with it and get used to it, because they, sort of, have to. They won’t change the CMS they chosen and are using on sometimes half a dozen websites…

    On an other side, a plugin developer will have to provide a wide range of options to satisfy its users, and encourage the adoption of its plugins. No options, not much users.

    Also the Cyanogen mod project has been widely adopted and pledged because of its huge amount of options. Whereas I now find this project provides too much options making difficult to find the one you need… But it is clear that without those the project wouldn’t have been such a success…

    My final word is that it is a case by case issue.

    1. The difference is that Cyanogen is made for that exact purpose. You could say the same of many WordPress plugins, which expose hidden configuration for those that actually need it.

      The point Nacin is trying to make, however, is that most people don’t need these sorts of things. Cyanogen has a relatively small userbase compared to the stock iOS software, and many people (myself included) find the preferences in stock iOS to be plenty.

      My advice to plugin developers is to make things available via filters, and remove them as preferences, where that makes sense. For a feature that will be used by a knowledgable 10% of your userbase, adding a couple of lines to a functions.php is fine.

      1. It is Cyanogenmod, not Cyanogen, (Cyanogen is the pseudonym of the original creator) and it is Android based, not iOS.

  2. I have noticed that there are some premium themes that are just shy of being able to make the tea or coffee. Its a good thing if the user is keen on customising, but I am glad sometimes to see that actually the default settings work really well as it can get awfully confusing.

    It may be an idea to have them stored in functions.php (or even as a menu function) and then if the user can (or wants to) they can enable the features individually and separately.

    For example – the WordPress Importer is one ‘plugin’ that does this. Most users will not need to use the importer, so it is only installed when necessary.

    I am still wondering what are the half-dozen options are that Mr Nacin has in mind? 🙂

    1. I am still wondering what are the half-dozen options are that Mr Nacin has in mind?

      “WordPress Address (URL)”, selectively. Encoding through pages and feeds (once set to UTF-8). Size of the post box (you can just drag it).

      Old stuff we could do without a UI: Post by Email (technically 5 options) and Update Services.

      1. Ok, with all of this in mind, after preferences or options have been added to software and have been left untouched for years and or version releases, how do you handle removing those options?

  3. In principle, I agree.

    But like most principles, when it becomes a mantra and many people get involved, “religion” takes over and it become dogma. More specifically, with WordPress one of the things I see that happens too often IMO is that significant use-cases for which those deciding simple are not familiar shortchanged and it’s justified on a “moral” basis. And I’m especially referring to things where the options are needed are hooks and not just UX options.

    What would I like to see? Less religion and more thoughtful consideration of use-cases that may not be immediately understood by those doing the deciding. FWIW.

    P.S. To be clear, this isn’t about any specific person; it’s just generally about use-cases getting dismissed prior to being understood. Or as Havoc said:

    …some preferences also have important benefits – and can be crucial interface features.

    1. Amen. It’s discouraging how much of Core doesn’t have filters and actions available. As a plugin author, I try to add hooks for pretty much everything, and am always open to adding more upon request. I don’t understand why we would want to place artificial restrictions on how people can customize and extend WP.

      1. Ian, there’s more than 2,000 apply_filters() and do_action() calls in WordPress, and many of them are quite powerful. This blog post had nothing to do with filters — we add dozens of them every release, often at the request of developers. Rather, it was a restatement of our desire to keep UI options to a minimum.

        1. I was responding to Mike’s comment where he said, “And I’m especially referring to things where the options are needed are hooks and not just UX options.”

          I think he was saying that hooks are a type of option, and one that can be easily added without cluttering settings pages, but there still seems to be some resistance to adding them when the specific use case isn’t considered “valid”. I think that relates to the post because the “Decisions, not options” mentality may be bleeding over from UX options into hooks as well.

          I agree that core already has a ton of hooks, but I still run into occasions where they’re missing, and I personally haven’t had much luck when requesting new ones. #16849 and #14380 are two tickets I’ve opened that need filters, and they’re both over a year and a half old. One of them doesn’t have a patch, so that’s my own fault, but the other does and it’s still been largely ignored.

          1. Hi Ian,

            I was going to follow up and say thanks and reference open tickets, but I just realized one of the ones I wanted the most got resolve 7 weeks ago, thanks to @nacin. Props! That and the admin menus that are now getting rewritten have been by far my biggest issues.

            But my ticket was 18 months old so I feel your pain. Hopefully they will address for 3.5 too.

  4. You making it simple by pretending it is.

    In the example given, let’s say we decide an Android unit is a mass storage device and that’s it.

    Suddently the device can not be plugged into anything that expects a camera. Parts of your user base now has a useless camera that does not sync. They’re not happy.

    Now Apple handles that by catering to 1/20 of the market. They mark up the price accordingly. That works for them and is a valid business case, but it’s obviously not for everybody.

    1. Or, you could always act as a camera unless the device signals that it can act otherwise. Computers could signal this once you have a proper driver installed. Take for example the iPhone, which acts as a camera device to the computer, but can be synced through iTunes through the same connection.

  5. excellent post, well said. reminds me of “Getting Real”, the book by 37 Signals. They also continuously stress the build-less / avoid-preferences mantra

  6. Don’t add settings screens simply because you know how.

    Well said. I’ve made a few themes for limited distro. And I tell ya, as I was learning, I thought it was so frikkin cool to give giant options menus. Man, you could do anything to my latest theme through one option or another. It’s kinda silly honestly.

    I’m reeling it waaaaaay back this time around. I’m just working now on a new theme for my personal site (which I’ll probably hand off to a few friends). There will be very limited options this time round, if any.

  7. I have just finished writing a blog post on choosing plugins. While writing, I realized that the choice is overwhelming and frustrating. Choosing a simple related posts plugin and configuring it has become a difficult task despite so many excellent choices.

    The good thing about WordPress or any other open source software is that, as it grows the users and contributors take on the role of teachers and educators as well. So at times when there isn’t an obvious option to do something people can always search and find advance options.

  8. “Don’t add settings screens simply because you know how.”

    Yes. Add settings screens because there is a need for the setting. For instance, I’ve noticed that many, many plugins that are meant to add functionality or content to the post screen are set to Administrator only by default. Unless the plugin author adds support to make the plugin visible to the other roles, I have to go about the task in a different way entirely which is just as, if not more, frustrating than having “too many options.”


    Balance the options against the anticipate needs of the users. No choice can be worse than some choice which can be worse than too much choice.

  9. In open source – respect the community.

    How to show the respect ?

    It’s in the process before arriving at any decision.

  10. Like a few others have already stated above, I agree with this premise, to a point. Like the very problem this philosophy is designed to address, there are levels of diminishing returns as you remove preferences, particularly in complicated software.

    To manage this , I use this rule of thumb when thinking about my users and any preferences or alternate behaviors for my software:

    -If more than 40% of my users will want to control this behavior, add an obvious preference, and make sure to choose the most common behavior as default.
    -If more than 20% of my users will want to control this behavior, add an “advanced” preference, and make sure to choose the most common behavior as default.
    -If less than 20% of my users will want to control this behavior, consider adding an advanced preference, but also consider not offering the option.

  11. I agree, less is certainly more in this distracted world of the internet.

    I do wish though there was an option to filter for plugins that are compatible with the version of wordpress a website is using when looking for a new plugin.

    I know this probably would never happen but wordpress built in search is not great especially relative to google. Would be great if they just used Google search functionality would make searching in the backend a dream.

    ‘The Shallows’ by Nicholas Carr is a good read on how the internet affects our brain and certainly leaves us with too much distraction.

    Sorry for my ramblings Im procrastinating….

Comments are closed.