(Image courtesy of Maura Teal)

I’ve written now a couple of times about what I think the WordPress community can learn from Drupal, and specifically Dries’ keynotes at DrupalCon, which I always make time to watch.

Now it’s time to talk about some learning in the other direction.

The occasion isn’t Matt Mullenweg’s State of the Word talk from WordCamp San Francisco, though those are always worth watching, nor his recent interview on WP Tavern, though that’s also worth listening to.

Instead it’s a talk by Aaron Jorbin at WordCamp Philly on Why WordPress Works This Way. (The video isn’t yet up on WordPress.tv – I will embed it here when it is).

Embedded below are his Aaron Jorbin slides WordCamp Philly – click once on a slide to advance – once your focus is in the iframe you can use the arrow keys to go back and forth. (I’ve started on slide 35, which is where he starts to get into Philosophy Driven Development):

Jorbin did a fantastic job articulating how the philosophy of the WordPress project drives development, based on a clearly articulated goal of democratizing publishing, and a set of tenets for what that translates to as a development approach.

Out of the Box

The idea is that WordPress should provide immediate utility – should be usable immediately out of the box, without requiring excessive configuration or dependency management.

Whenever a new feature is introduced into WordPress, it has to be done in a way that doesn’t require excessive configuration before it can offer value – that’s resulted in the famous five minute install, and a focus on preserving that initial experience.

Of course as users climb the sophistication curve, there can be some “progressive disclosure” of more advanced options – exposed for example as filters or config file edits – but they should never be required to get core functionality working.

Design for the Majority

The majority of folks who will use WordPress are not developers – in fact they aren’t even necessarily technical. When design decisions (including decisions about features in core) are being explored, if they are not useful to the majority of users they probably don’t belong in core.

A feature that a majority of users disable is not a feature, it’s a bug. Jorbin’s own first patch was rejected – but he now realizes that was the right decision.

The proper persona for which a CMS is designed is not the developer community who will use it to build sites, but the end user community.

Decisions, Not Options

Jorbin described Havoc Pennington as perhaps the most important contributor to WordPress who has never contributed code. (See his writing On Preferences or Nacin’s post from 2011 on the same topic).

Jorbin connects this to the question of Auto Updates – there was never even a discussion of this being an option a user has to enable – because every option imposes a design, technical, and cognitive cost on the project. (Of course this doesn’t mean auto updates can’t be turned off – just that this isn’t exposed as an option in UI, it requires a filter).

Clean, Lean, and Mean

Jorbin didn’t specifically address this one, or highlight it on a slide, but obviously his examples (“sometimes not adding a feature is a feature” are consistent with this value as well.

Striving for Simplicity

This means recognizing that ease of use matters – in a core strategic way, not as an afterthought or to be added once the core feature set is in place. Jorbin uses the removal of the link manager (which was done in such a way that new installs don’t get it, upgraders had it removed if not used, but folks using it kept it) and the more recent update to link pasting.

(If you haven’t noticed, in WordPress 4.2, highlighting some text and pasting a URL from the clipboard makes that text a link to that URL – an interaction so simple and intuitive that once you see it you wonder why it didn’t always work that way.)

This also relates to accessibility – simplicity and accessibility are often aligned, as simpler interfaces will be more easily made accessible.

Deadlines are not Arbitrary

Jorbin described the temptation to delay a release for that “one-more-feature,” and how that can become a quagmire that delays the release of truly useful functionality for end users. Getting functionality in front of real users in the real world as early as possible gives us the best chance to iterate on it.

Anyone who has dealt with the four year cycle of Drupal 8 development, with many times where it was declared almost ready, or about to be released, can understand the frustration of end users who are trying to make decisions and plan.

Sticking to a more frequent, iterative release cycle doesn’t mean releasing poor quality software, it means not allowing “one more feature” to hold up all the existing improvements ready to be released.

Imagine if WordPress had tried to hold back 4.2 or 4.3 in order to get the REST API integrated – since it is already available as a plugin, there’s no need to wait.

The Vocal Minority

We’re all used to the 90-9-1 rule: 1% of the internet creates content on the internet, 9% interact with it (comment on it, respond, share, etc), and 90% just watch.

The trick is to recognize that the people expressing their feedback most vocally in the context of development discussions aren’t actually the majority. (The majority of users are non-technical, and don’t spend time in development discussions).

WordCamps and WordPress meetups have done a wonderful job of encouraging regular contact between developers of the platform and real end users: at the happiness bar, via WordPress.com as a widely used platform, and via specific outreach into the user community.

Jorbin highlighted all the things that were once controversial developments: Multisite, Menus, the Customizer, Inline Plugin Updates, Emoji support. (Of course emoji support wasn’t just about emoji support but also fixing a critical security issue).

The point isn’t that the development team (core contributors) should ignore feedback from other developers, but that we should always seek feedback from end users and realize that there often is a majority that isn’t speaking up.

Our Bill of Rights

Jorbin concluded by pointing to the one thing missing from the WordPress development philosophy – a specific articulated expression of what kind of community we want to design/encourage/shape. He pointed to Drupal’s values (“Teamwork, innovation, and openness in our community”) and Joomla!’s vision (“A community that is enjoyable and rewarding to participate in”) as counter examples.

(Recently the Django community published the Django Community Diversity Statement as well)

We do have a “Bill of Rights” in WordPress, but it speaks more to individual rights, based on the GPL and the four freedoms.

What does this mean for the Drupal community?

I’ve often heard the Drupal community described as a do-ocracy: whoever can do the work has more influence and gets to decide. There’s a certain appeal to that, in the sense that it aligns with the open source ethos of “patches welcome” – ie, if something is important to you, you should be willing to devote some of your own time to fixing it.

The problem, of course, is that often the actual users of the software aren’t able to do the work. I don’t mean to imply the Drupal community doesn’t listen to users – in my experience there is a tremendous interest in getting user feedback and trying to help solve end user problems – but that the Drupal community sometimes seems to prioritize the desires of developers and sitebuilders over the needs of the non-technical majority.

The WordPress community specifically and concretely articulates a set of philosophies which say that the goals of end users are more important than developer desires or technical purity.

WordPress works very hard to keep complexity hidden “under the hood.” In Drupal, very complex administrative UIs are common. There’s no doubt a Drupal power-user can use those complex UIs to produce some complex structured content types and relationships (along with a complex set of module dependencies and configuration for those which can be hard to replicate, share, or manage).

In WordPress, the custom post type creation UI isn’t enabled by default – you have to write code (or leverage plugins) to get to custom content types. But that also means you don’t paint yourself into a corner as a user without fully understanding the underlying API.

I think it’s telling that there really isn’t a “site builder” role in the WordPress community the way there is in Drupal. There are folks who build sites – designers and developers, including front-end developers and web developers – but they aren’t site builders in the Drupal sense of being power users of the administrative interface.

I’ve often said Drupal suggests using 10 modules and a “recipe” for configuration for how they all relate to each other to avoid writing 10 lines of PHP code. WordPress will encourage you to write 50 lines of PHP code to avoid one configuration step on the user.

(See my talk on Structured Content in WordPress and Drupal from NERD Summit 2014)