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.
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.
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.