Joomla World Conference

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.

Speaking at WordCamp San Francisco

WordCamp San Francisco has announced their final round of speakers, and that includes me. I’m giving an advanced development talk on Saturday called Current User Can Watch This Talk. Props to fellow lead developer Mark Jaquith (who is also speaking) for coming up with that clever talk title. Here’s the description:

At first glance, the WordPress roles and capabilities system is simple. Users have roles, roles have capabilities, and plugins can make simple changes to them. Done, right? Not quite: You’ve been doing it the hard way. A deeper look inside the API reveals a surprising amount of flexibility, including the single most powerful (and dangerous) filter in WordPress. In this talk, you’ll learn how capabilities are “mapped” to other capabilities, and what the difference between primitive and meta capabilities means for your plugins and custom post types. We’ll explore the true hidden powers of the API, like using capability mapping to selectively grant and revoke privileges on the fly, making complex user management more maintainable.

The single most powerful and dangerous filter in WordPress? That sounds both ominous and awesome if you ask me.

If you’re interested in presentations aimed at advanced developers at WordCamp San Francisco this year, make sure to also catch the illustrious Mike Adams and Andy Skelton. Mike is talking about security in “Three Security Issues You Thought You’d Fixed.” Andy will be presenting a new approach to performance in “How pcntl_fork() Can Save Us.” I’m really looking forward to what they have to say and you should do.

I’m also looking forward to talks by Will Norris, Nikolay Bachiyski, and Helen Hou-Sandi. Together, those are six names who have greatly influenced not just WordPress development, but my own work and the contributions of many others. Check out the full line-up here and here. A few tickets are still available for the July 26–27 conference.

I also hope to see a lot of people at the Contribute Day on Sunday. I’m helping organize that, and WordPress 3.7 will be underway by then — more to come on both soon.

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:

WARDNET Inc. on Twitter

Russell Heimlich on Twitter

OpenWest Conference on Twitter

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.