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.

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.

If a feature or product were legitimately easy the user would not be writing in to support about how stuck they are. Sure, some percentage of users will find questions to ask about any interface. But do you want to start the conversation by assuming the user falls into that percentage? You venture to learn much more if you assume the software is wrong, not the user.
— Andrew Spittle, “Avoiding Easy”

This post by Andrew on avoiding the word “easy” in support is golden, but perhaps predictably, this is the part that stood out when I read it. If your user is confused, chances are, the software is wrong. No bugs necessary.

Required reading is what Andrew linked to in this paragraph: Joe Flood’s blog post about a comment Matt Mullenweg made at WordPress DC last summer, “The software is wrong, not the people.”

Did you know that before you could write crazy shit on Tumblr and WordPress, people had to type their crazy shit up on what was called paper — and distribute it by hand, reaching the few paranoid conspiracists within walking distance.
— Jon Stewart

That was The Daily Show’s Jon Stewart on Tuesday night, referring to Ron Paul’s decades-old newsletters. Just another way to describe democratizing publishing.

Bonus: Ron Paul’s 2012 website runs WordPress. And he’s not the only one.

Double Bonus: Comedy Central’s Indecision site is WordPress too. (I knew thedailyshow.com wasn’t, but it didn’t take long to find one that was.)

Updated with the clip:

The Daily Show with Jon Stewart

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.

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.