Instead of showing the user an alert that something might not work, maybe we can build a smarter algorithm. Instead of asking the user to make a choice up front, maybe we can set a smart default and see if there is high demand after launch for more customization.
— Rebecca Rolfe on the Google Chrome team, interviewed in The Badass Women of Chrome’s Security Team in Refinery29.
(More on making decisions, not options.)
I’m attending Joomla World Conference in Boston this weekend. Wait, what?
WordPress founder Matt Mullenweg is giving a keynote address on Sunday. I’m really glad we’re here, as engagement across communities is vital. Too many web communities are isolated, and I suspect there is a lot the WordPress and Joomla communities can learn from one another.
The two projects have a lot of similarities: we love open source and the GPL, love-hate PHP, and have sprawling communities and ecosystems. We’re also both forks of other software (b2 and Mambo), and we are both trying to advance and evolve quickly, as well as better define what exactly we are (blog/CMS/platform/framework). Of course, there are many differences. I especially want to talk about and compare development philosophies. I quote from and reference our philosophies document often, and we practice them as much as we preach them. Among them: making decisions instead of adding UI options, designing for the majority of users, stressing the importance of deadlines, and building something that is lean, fast, and works out of the box.
We receive a lot of praise for our user interface, and we strongly believe that the user experience comes first. But for us, that includes making sure we’re always backwards compatible, even across major versions. While we shoulder more technical debt this way, we’ve found it is better than passing that pain off onto our users and the other developers in our ecosystem. The UI is awesome, but our commitment to BC may be the most understated reason why WordPress has grown to power 20 percent of the web.
One section on that philosophies page actually needs to be updated: in “Striving for Simplicity,” we talk about how we worked to ensure WordPress can be updated in a single click. But in WordPress 3.7, released last month, maintenance and security releases now occur automatically. Zero clicks given! A self-updating web application? Without breaking anything? Yes and yes. The technical challenge was immense, but so was communicating it to our users and developers. If anything ever fails on them, they won’t be inclined to trust us again — whether that’s an update or the simple act of trying to save a post. (That’s also why we focused on stronger autosaves the previous release, WordPress 3.6, which was released only two months prior.)
I’ve gotten a warm welcome so far. Want to talk about development philosophies? How releases are run? How our projects are organized? How decisions and features are made? How to evolve our complicated platforms? Want to chat about lowest common denominators, old versions of PHP, crappy servers, and the crazy things we all see in the wild? Why do we do X? Why on earth don’t we do X? Great. Come find me. I’ll be walking around wearing a WordPress shirt, or you can hail me on Twitter (@nacin).
I have some stickers as well, if you want one.
Back in 2011, I wrote about how we need to make decisions in open source. This is not a new idea — it is rooted in the guiding philosophies for WordPress to make decisions, not options.
Perhaps unsurprisingly, Hacker News is now up in arms about Firefox 23 removing the “Disable Javascript” option. I’m really glad to see ex-Mozilla guy Gregory Koberger with the top comment there, linking to a fantastic piece called Checkboxes that kill your product. “A little historical baggage can be a dangerous thing when multiplied by a few hundred million individuals,” wrote Alex Limi, who does product design strategy at Mozilla. (I had a chance to meet Gregory at a conference in 2011 and he’s a great web dev follow on Twitter.)In WordPress 3.5, I spearheaded a quiet but major purge of UI options. We removed ten of them. And we moved another off its own page, which let us drop down to six settings pages, down from eight in 2010. My napkin math shows we removed 15 percent of all settings. That’s a huge improvement. Some of these were break-your-site options. Others might cause confusion. And we have ongoing efforts to simplify or improve a few other settings as well.
When talking about decisions versus options, I often tell the story of Firefox 4’s change to tabs on top. I even watched a seven-minute YouTube video explaining exactly why this was a better user experience. (And I couldn’t agree more.) But then, at the end of the video, after all of the convincing arguments, they mention there is an option to put it back. My heart sank. It was a compelling video, but the community forced them to compromise by keeping in core a completely separate workflow, despite making a strong statement that it was clearly inferior. Firefox is highly extensible. An extension could have changed it back. By keeping it in Firefox core, you now have double the user flows to test, your QA testing suffers, users suffer, everything suffers.
Firefox may be the people’s browser, it may be the one true open browser project, but that doesn’t mean it is a kitchen sink. I didn’t actually realize that Firefox still had the Disable JavaScript option. I have been using an extension to toggle JavaScript in Firefox, as sometimes I have to test no-JS situations. The fact that I didn’t know the option existed, though, is only one indication that this is a problem. This single option enables a user to do so much damage to their web browsing experience that it is absurd for it to exist. This is Limi’s point.
I can’t quote from the writings of GNOME contributor Havoc Pennington enough. His posts did a lot to inform early development of WordPress, and continue to make an impact today. Here’s what I shared in 2011:
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.
For more written by Pennington, see these essays from 2002 and 2004.
Perhaps tellingly, I also wrote then “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.” In WordPress 3.5, the circumstances were right. Promise kept!
Addendum: In that long Hacker News thread (300 comments and climbing) Gregory also commented:
Try an extension? Power users aren’t the target market for this decision, and that’s why add-ons exist.
This is also a great time to review the sections Designing for the Majority and The Vocal Minority on the WordPress philosophy page.
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.
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.