Firefox makes a decision, removes an option

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.

Keynoting php[tek] in Chicago, May 14-17

I’m excited to announce I’m giving a keynote address at php[tek] 2013. It’s a fantastic PHP conference put on by the folks behind php|architect. “The premier professional PHP conference with a community flair,” #tek13 has a rockstar speaker line-up, four tracks of content, and a day of training. I’m thrilled to be attending the conference — I also attended #tek11 — let alone speaking.

Last night I tested a few ideas at the DC PHP meetup and got some great feedback from the attendees. Some early reviews:

I’m continuing to conduct a lot of research for this talk. There’s a lot WordPress has learned over the years, so I’ve been searching through the codebase and old commit messages, as well as compiling a ton of data and statistics. If you have anything you think might help, please contact me. Here’s the full talk description:

WordPress is Everywhere: Extreme Portability as a Double-Edged Sword

WordPress has tens of millions of users worldwide and powers over a fifth of new sites. But such a large and diverse user base presents unique challenges, and as it approaches its tenth birthday, the WordPress codebase is showing its age. So why is it so ubiquitous?

The answer lies not in its UI, UX, ecosystem, or community, though those are certainly among its strengths. The answer lies instead in a core philosophy that holds the user above all else.

This user-centric design starts not with the interface, but rather with the code itself. Developers should approach software development with an unwavering promise they will deal with the nonsense instead of passing it off to the user.

Some WordPress positions might seem draconian and inflexible. Backwards compatibility is almost never broken. The technical requirements appeal to lowest common denominators. But because the project maintainers deal with all the pain — technical debt, difficulties with PHP, working on as many server configurations (and misconfigurations) as possible — its users don’t have to. Thanks to the WordPress project’s portability efforts, you can pick a web host or a PHP configuration at random and WordPress will run on it. Because of this, adoption has soared.

The way WordPress operates is not for everyone. But whether your projects are used by 10 users, or 10 million, it may help you to see your code in an entirely new light.

Tickets are still available. Hope to see you there!

Page templates in subdirectories, new in WordPress 3.4

In WordPress 3.4, themes can now place page templates inside a subdirectory of their theme.

I’ve spent much of the 3.4 development cycle working on a new API called WP_Theme. But it’s not something you’ll find in the release announcement.

That’s because the vast majority of plugin and theme developers will never use it, nor should they. It’s an under-the-hood enhancement that was aimed at strengthening our internals, and it enabled us to improve quite a bit. For example, we were able to find huge performance improvements in both memory and speed. And it enhances the ability to localize themes. (More on these changes when I start working on the 3.4 field guide.)

It feels nice to be working with a modern, well-written API, even if I’m the only one using it. That’s okay, because look how easy it was to add support for page templates in a subdirectory. This is just the beginning.

Child themes can override these templates the same as before — the child theme will just need to create the same directory structure to do it. (So, /page-templates/one-column.php needs to be overridden with /page-templates/one-column.php, not /one-column.php.) And yes, we’re only looking one level down.

Updated… Caution: Renaming a page template — and that includes moving all of top-level page templates into a directory — will unassign that page template for all pages currently using it. This is a new tool in your toolbox, but use it wisely.

WordPress: So Easy a Congressman Can Do It

The U.S. House Committee on Oversight and Government Reform launched a new site on WordPress today. This is really cool for a few reasons. Rep. Darrell Issa tweeted about it this morning, saying WordPress is “rare” for government and said it was “to support fast improvements in response to your feedback.”


Government moves at a pace best described as glacially, so for them to recognize that WordPress can help them react quicker, that’s just huge. I’ve learned in D.C. that ease of use and speed of development are very rare things for .gov sites, even those built on open source. Not to mention cost-effectiveness in an age where federal government IT procurement is being upended. Look, they even created cheesy WordPress-in-government infomercial:

The video takes a shot at bad government websites, and while the new site isn’t the prettiest thing in the world, I like the point they’re getting across: Government can excel on the web using the same free publishing software as many of their constituents. It won’t be rare for long.

Related: Ben Balter’s post on WordPress and government from last week is making waves.

Bonus: The Consumer Financial Protection Bureau recently gave their WordPress site a new coat of paint.