About Andrew Nacin

Hi, I'm a developer of WordPress and a member of the core commit team. I live in Washington, D.C., and work as a Tech Ninja at Audrey Capital. Read more... Don't forget to follow me on Twitter.

Theme Foundry: “Don’t Steal My Theme Options”

Link

Don’t steal my Theme Options, from The Theme Foundry. It seems at least few people interpreted my post last week as suggesting there should be no options. While I think that software should just work, I also suggested that a half-dozen options could be removed from WordPress, not the other 50-something options. Nonetheless, the Theme Foundry post is a great case study in how you should be approaching options — in a careful, meticulous fashion. “We talked it over, and decided we’d go one-by-one through the options and scrutinize like madmen.” That quote makes me want to go find and don my Theme Foundry t-shirt.

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.

Hiding the welcome panel in WordPress 3.3 multisite

WordPress 3.3 introduces a new welcome panel designed to provide a better experience for new users installing WordPress for the first time. It’s a great idea, but one that may not work for all multisite installations. So I’m releasing a plugin that networks can use to dismiss the panel for new sites and users.

Try Hide Welcome Panel for Multisite, version 1.0. Only works for networks, and the plugin must be activated from the network admin.

Want to know how it all works? The plugin’s inline documentation contains the technical details.

Credits page for WordPress 3.3

The WordPress 3.3 credits page was updated today, for likely the final time. In five months, there were nearly 1,200 individual changes to WordPress (and counting).

The credits page lists every individual who contributed to the latest release. A few stood out for their contributions, not just of high quantity, but of tremendous quality: Dominik Schilling (ocean90), Cristi Burcă (scribu), and Sergey Biryukov. The three are listed as contributing developers to 3.3. The core team — including guest committers Jon Cave (duck_) and Daryl Koopersmith — worked with these three daily, and they had a collective hand in nearly every major task this release.*

There were also three individuals added to the ‘Recent Rockstars’ group for their recent contributions to core development. This release we chose Chelsea Otakan (chexee), Helen Hou-Sandi, and John Blackbourn (johnbillion). All together, the six contributing  developers and rockstars we’ve recognized contributed more than a fourth of all Trac comments and two-fifths of all props.

If you want to see the full list, click the WordPress icon in the 3.3 toolbar and head on over to the credits page, or wait for the release post (coming soon!). Maybe I’ll also experiment with a word cloud again as I’ve done in the past.

In WordPress 3.4, we plan to recognize first-time contributors on the page, so if want to see your name in lights on the credits page, contribute to WordPress.

* Fun fact: Average age of the five mentioned in this paragraph: 23.