Wordpress might not be better than Drupal, but it's still a worry

In other news, I've got massive piles of apples and oranges I'm trying to get rid of. It's to make room for some coal. Can you give me a hand?

Recently a blogpost discussed Jen Lampton's superb conference session: "Wordpress is better than Drupal: developers take note." The author said that they really liked the session, but

  • Wordpress isn't actually better than Drupal
  • Because you can't compare Wordpress and Drupal
  • So the usability issues arise from a false comparison
  • And here's what's going to solve our problems instead

In the first paragraph or two it managed to simultaneously both praise Jen's talk and completely deny the core message of it. I think that highlights a number of trends in the way that the Drupal community as an aggregate (though by no means as a whole) tends to think about usability versus technology. Actually, I think the communities behind most large open-source projects behave this way, and it's ones like Wordpress or Ubuntu that are actually unusual. But I think it's worth talking about this phenomenon in the context of Drupal.

Apples and oranges

Anyone who argues a point of view can be sure they've ruffled some feathers, when someone else complains that they're "comparing apples and oranges." It's a definite sign that the complainer doesn't like the problem that's been raised, and instead wants to treat an informal analogy as if it were a keystone in a tense, logical structure; then attack the analogy instead. It's like hurling around cries of "ad hominem". It doesn't really prove or solve anything. Apart from anything else, what if my point is to compare apples with oranges?

Whatever you compare Drupal to, whatever your motives, whatever important (often fundamental) issues you want to highlight about the way Drupal does things... eventually you'll have to compare Drupal to something that isn't Drupal. You will have to compare the apple to some other fruit. That's the only comparison worth making. Are we just going to forever compare Drupal 5 to Drupal 4.7, Drupal 6 to Drupal 5, and gradually Drupal 7 to Drupal 6, purely as a teleological exercise in patting ourselves on the back? Of course not! And however close the something else might be to being Drupal, there'll be some slight difference, which will inevitably provide an opportunity for hairsplitting. Maybe we could call it fruitsplitting instead, because that difference in variety of fruit can be used as an excuse, if not a reason, to dismiss your broader motivations in making the comparison.

"X isn't a CMS." "Y isn't in PHP." "Z isn't aspect-oriented programming." "P is aspect-oriented programming, but it's intended to be purer than Drupal, with pointcuts." "Q doesn't have a genial tousle-headed giant as its benevolent dictator."

Apples aren't oranges, but then some apples aren't the same as other apples, either. Apples come in all sorts of varieties. So you can even compare apples with apples, if you like, and someone will come along and protest. Except they won't so often these days. Want to know why? Well, here's a story about apples, from the ever-readable George Monbiot.

Briefly: there used to be a huge market in different apple varieties. Hundreds and hundreds of varieties: Belle de Boskoop, Michaelmas Red, Brown Cockle. And then the supermarkets came along, and they decided that they could essentially compel their customers to standardize on a handful of apple types: Royal Gala, Jazz, Cox's. They did it, because the customer didn't really mind what type of fruit he was eating.

And that was essentially the end of the line for most types of apples. "Extinct, extinct, extinct." Most of them just gone. The free market effectively wiped out those varieties, ruthlessly and ignorantly. It reduced the number of breeds to a tiny fraction of what it was. People compared apples with other, different apples, and they just picked... apples. Nobody will fruitsplit between apple varieties now, because they're just all apples.

Drupal already has plenty of greengrocers, fruiterers of the programming world, people who rightfully and meticulously care about, and tend with love to, our apples and our oranges. But the prize, the broad user base, the real success story... that all lies in attracting non-greengrocers. And they'll just think: "Apples. Oranges. Other apples. Whatever." They probably won't care about different types of fruit; they've been told that their website has to have its vitamin C for the day, so they'll get the apple that's easier to get into, and to hell with your awkward-to-peel oranges. If your business model depends on selling individually wrapped fruit to other greengrocers, then good luck with that. I'm off to take some coals to Newcastle.

Who's going to tell the customers?

The blogpost suggests that:

Instead of comparing a toolset and a product, there are other, appropriate comparisons that businesses and developers should be making...

Well, it's wonderful that I know that now. But who's going to tell everyone else to change their ways? Is there going to be some sort of government-funded outreach programme? Will we all be making some sort of world tour? I try to picture a random user appearing, like a superhero in a flash, in offices around the globe. "Hark! I hear someone in Mumbai making comparisons between Wordpress and Drupal that appear reasonably valid to them based on their expectations derived from: Drupal websites, Wordpress websites, and Yet I must intervene, swiftly! To the nearest train station!"

Anyone who decides that the solution is to tell businesses and developers what comparisons are appropriate will end up like Wowbagger the Infinitely Prolonged, travelling in time so that they can tackle simultaneous disparagements of Drupal. We can't rely on that: Drupal ultimately has to be able to say this for itself: it should be obvious to these businesses and developers what Drupal should be compared to. Otherwise these businesses and developers will continue to make comparisons based on the (admittedly incomplete and sometimes wrong) information they have available to them. 

Saying what comparisons end users ought to be making is a lot like that other canard, "educating the user." Unless you're talking about a site's administrative user base, people at a client who you could count on one hand, that's a pretty mammoth task. Who gets to ensure that such universal education about the vagaries of, say, module weights, or the vagaries of CCK field display, eradicates doubt in the same way that we once got rid of smallpox? Similarly, if Drupal's success against Wordpress depends on people only ever making the comparisons we want them to make, we're in trouble.

There's also tendency to call Drupal a CMS, right up to the point where someone complains it can't do what a CMS does out of the box. Then it's called something else. A toolset. A content management framework. A management framework toolkit. A content toolkit framework management system tool. It might deflect debate, but ultimately the jargon just puts people off. You might have won the battle with potential new users, but the war goes to whichever CMS with limitations that accepts from the outset that it's a CMS with limitations, and tackles those limitations---in Drupal's case, most notabbly user experience and getting started with it if you've never heard of Drupal before---head on.

The documentation on is pretty impenetrable to the average newbie, but if you can figure it out then you get the impression that Drupal is basically a CMS, a bit like Wordpress only with other (waves hands) stuff. So it must have a WYSIWYG editor, only somehow more so, right...? And the user experience of Drupal 7 is a great improvement, much like improvements that have already happened in Wordpress; but, despite the fantastic news that we're moving to beta releases, only greengrocers are using that right now. If we want non-Drupal users to make the right comparisons about Drupal, today, will we really fix it by arguing about distributions; products; toolsets; downloads; projects; modules; features...?

The technology will save us, of course

Here's a handy tip. Technology alone will probably never save you. You only have to have sat through Jen's talk, and to have read about Hagen's similar Wordpress-Drupal-Joomla walkthroughs in the unconference on DrupalCon Monday (I blogged about Hagen's marvellously excruciating walkthroughs on the g.d.o usability group) to know that the technology won't save us. Or rather, specific bits won't save us. Aegir won't save us. Products won't save us. Distributions won't save us. The redesign probably won't save us either, because that's nearly finished and yet we're still denying the very usability and expectation problems that are still in plain sight.

Don't get me wrong. All of these things are great tech--really fantastic, mindblowing tech---and they solve specific problems that developers come across. I think drush make is one of the most exciting bits of Drupal I've ever used. But I'm a developer! Of course I will think that! Not only do I know how to set a Drupal site up in 15 minutes, but I also know from experience how to avoid the many, many ways in which it will take you two days. These tools  don't fix the fact that Wordpress is easy to use. Wordpress just works. Drupal needs tools to help you install it, and command-line fu before you can even make those damn upgrade errors go away, go away, please just go away.

You can't wait for technology to solve these things. Distributions won't change the fact that you can click around the website for ten minutes and still not be completely sure what it is, or how to use it. The learning curve is still too large; and I'm just talking about how you use, not how you use Drupal. Until everyone in the world is re-educated to know, and care, about what a distribution is, and how it's subtly different from just getting the blasted thing to work, then distributions won't save us.

What will save us is usability. User experience reviews. Jen Lampton's talk. Hagen Graf's talk. Watching users try to get to grips with this thing we love, when they just don't love it so much, won't excuse it as much. Feeling the cringe when a new user falls into the same trap over and over again, and knowing you won't be able to appear on their shoulder to help them. Then, though: this is key. You can't just say, "well, we'll let the themers fix that," or "maybe the forums can discuss it," or even: "when users ask for the wrong thing it is rarely, if ever, the right answer to humor them." Instead, you have to accept the application has a usability problem; and work out a plan fix it, right there and then. Developers, deciding to fixing usability problems above functionality problems. Again and again and again. Test, observe, cringe, fix, repeat.

It's a slog. But it could work where technology won't, because ultimately end-user functionality with serious usability problems will end up massively underused, and as far as the greater course of Drupal is concerned it might as well not be written.

Does this matter?

I feel like I've gone on a bit, and if you feel like that too then I apologise. After all, the usability community in Drupal is healthy and growing. People are starting to take usability seriously. But I feel like there's still no UX standards to point to, with the same weight and depth as the coding standards. Talk is silver; code is gold; UX is presumably 24-carat meh. There are still no easy ways of sharing usable interface patterns as easily as one might share patches. Usability is still a teenager, and it's easy to freeze it out of the conversation it in favour of adults talking about established technical preferences. Usability needs cultivating, and the user's behaviour needs to be king, whatever comparisons that user might make. We're right to worry about Wordpress, but that's a good sign! It means that Drupal is doing something right. It's worrying about the user.

Maybe, returning to the original blogpost, "the time is right for Drupal products." I'm happy to agree with that. Featurization and ease of deployment certainly suggest that productization will swiftly follow. But that has nothing whatsoever to do with the usability talks. It really won't solve the fundamental problems that Jen's talk tried to address.

One thing she said really stuck with me; as a developer, I took note. Well, I took lots of notes, but here's what stood out for me:

"Wordpress is behind us, but they can move fast, and they're looking at us."

With version 3.0, Wordpress quietly turned itself into a CMS. Maybe they saw fields were working well for Drupal, and thought: we'll have that. "It's simple but it'll do: let's ship!" Bang. Instant easy CMS. Usable too.

That's the point, in the end. Usability is not a nice-to-have. It's the canary in the cage, the indicator species: when usability suffers, it's telling you about lots of other attitudes that lead to the user being made unhappy. Whereas Wordpress emphasizes usability; it's friendly to the user out of the box; with things rich-text editing that the user wants to have without any issues; with straightforward media management; and with upgrade methods so simple they're frightening.

Drupal? Drupal's a brilliant, smart, well-oiled, massively functional framework (it's far more fun to develop with than Wordpress.) It's a CMS, except when it's not (but when it's not, it's still a rich seam for developers to mine.) It's still tricky for newbies to install (but developers learn the tricks.) Image handling is odd, and if you pick the wrong method early on you're in for a lot of pain later (but developers know which one to pick.) Upgrading modules is not a one-click experience (unless you're a developer and you've played with drush.)

Yet with all that in mind, here's a question. If you'd never heard of Drupal or Wordpress before, and you were 90% of the internet, rather than a developer; if you were the same sort of user as a client's marketing guy, who's never written a line of PHP in his life; based on the experience of trying to get each of them up and running yourself, which would you choose? Apple or orange?

BarCamp Transparency and Oxford Code Jam

This town is geek enough for all of us.

Almost certainly no progress on those copious and comprehensive notes about BarCamp Oxford this side of Easter. But it's worth mentioning two offshoots from the weekend's discussions that look set to become big events in their own rights.

Sylwia Presley, Ben Werdmuller, Marcus Povey and others are beginning to organize a Transparency BarCamp, to talk about the ethics of social media and web 2.0, Open Government and individual freedom, and even topics like cyber-activism. Meanwhile another group, including the likes of Matt Thorne and Oleg Lavrovsky, is hoping to try their collective hand at Oxford geek jams, collaborative all-day coding events.

The local geek community---most obvious to me personally at the Oxford geek nights of course, but to others through the Oxford Flickr Group or the Agile Oxtremists---has always been strong and supportive, but in quite a slow-burning way. Suddenly it's like someone's given those flames some air, and the Oxford geek/social scene has warmed up. It feels great.

Playing with Django: a fretless experience

I've been trying for twenty minutes to shoehorn a joke about Grappelling into this excerpt.

Django continues to gather momentum towards its imminent 1.0 release. The 1.0 beta 1 is out; the developer documentation has been refactored; it already places nicely with Python's powerful debugging and logging tools; indeed, all is proceeding according to the roadmap, more or less. James Turnbull will be speaking about Django 1.0 at the eighth Oxford Geek Night this Wednesday, and it looks like he's got plenty of triumphs to bulletpoint for us.

An Oxford Django sprint had been mooted for this weekend. I didn't hear much more about it, but to be honest I had the great opportunity to actually have my own sprint---against 1.0b1---in work this week, working on a fast-turnaround project. I definitely felt performance improvements, especially when running unit tests. It was also lovely to work on my first internationalized/localized site and to find that it was just a question of dropping in certain bits of middleware to make it work across six languages. We didn't have any translations in place, but I clicked on "Polszczyzna" expecting bugger-all to happen and then suddenly realised that the English-language link read "Anglieski." It's characteristic of Python's (and Django's) refreshingly plastic and just-works behaviour. Magic.

We did encounter one bug, involving model inheritance. I struggled for a while with registering with the project trac to report it. It's my first mediocre experience with Django: I waited a day or so for the arrival of an account-confirmation email, but eventually gave up without adding what would have admittedly been a me-too to an existing bug report. But then, email finally in my inbox, I chased it up just now, to find that it's been fixed. Today.

Probably much like Django itself, the project's interface with the user/consumer requires some past experience with its foibles, but the actual endeavour itself is fast, well-factored and puts most closed-source equivalents to shame.

I'm with Ignorant →

Never ask someone how stupid they are; conversely, don't be surprised if they buy books explicitly meant for dummies.

David at 37signals writes:

Self-deprecation is fine, just realize that there’s a dear line between embracing your own ignorance and ensuring a prophesy of certainty.

David's career path sounds similar to mine: although I played with Linux as an undergraduate, I didn't start programming until my PhD, and only really developed my XSLT, Perl and scripting skills prior to coming to Torchbox; since arriving here over three and a half years ago I've learnt "everything else", from Transact-SQL and Coldfusion to Django and Drupal. But until maybe eighteen months ago I really felt like I was behind the technological curve, yet couldn't quite work out how to get ahead. A year and a half later and I've clawed my way forwards, if not to that cutting edge then at least to the point where hacking away is no longer the effort it used to be, but I couldn't give anyone else any tips on how to do it.

One big problem is there are so few resources to help people over that gap---and there is a gap, not a continuous curve---from uncertain n00b to excited, interested programmer. Established OS communities can be cliquey and quite scathing, and it's hard to get into even friendly communities without prior knowledge of how these things work: what's the chain of command; do I need a CVS account; can I get a CVS account; how do I earn brownie points in this particular version of a meritocracy?

There's Wikipedia, of course. One of the few areas in which it isn't a tragicomedy in thrall to undeclared conflicting interests (Cornish separatists, religious cults) is its technical pages. But they're tremendously dry, and not at all of tutorial standard. That's not the point of an encyclopedia, of course, which you'll hear a lot of if you ask why your recent edits have just been reverted.

We need more tutorial sites like Why's Poignant Guide to Ruby, and fewer like ONLamp's An Introduction to Haskell. The latter is well written, and says a lot about programming languages in general, but it reads like the prologue to an entire Haskell book for professional programmers, rather than an actual introduction. Since visiting them both, I've actually written some Ruby (even though I didn't get on with it particularly), but I've just finally bit the bullet and uninstalled ghc6, still with its wrapper on.

Blog category:

Orl korrect at OKCon

Openness is about more than availability: it's about offering something the way you'd offfer a guest your tray of Ferrero Rocher.

Yesterday’s OKCon 2008 was great fun, if a long day! I’m still digesting the food for thought that the conference provided—many, small courses; over a dozen if you include the more open sessions after the keynotes, and each followed by a sorbet of questions and debate—so I don’t have a great deal to say about what I heard yet. The field of open knowledge, like that of open source ten or fifteen years ago, is still largely untilled and untidy, and many disparate groups are gradually but warily treading its boundaries, with only a few striking out into its wild heart.

Despite the argument of what constitutes openness being largely resolved in the open-source community, we still found rich pickings of our own. It’s trivial to define openness in, say, data, with its analogies to code; but it would be an error to equate data and knowledge or understanding thereof. The broad consensus was that open knowledge was a combination of both free-as-in-speech and free-as-in-beer, but also free-as-in-educated and free-as-in-enfranchised. In this way, its analogies lie more in open computing, or open web-navigating, than in open source: a combination of freedom, autonomy and opportunity. Solutions will therefore need to be a complex, messy combination of social, political and technical: less like Python, but more like One Laptop Per Child.

Ben Spigel, who made the connection between OS-then and OK-now explicit, missed the mark a little when he likened the OK community to Linux’s. After this conference, I think we need to stretch even further back, to such early efforts as the FSF and GNU. There are still moral complexities to be resolved, difficult decisions about direction to be made, and occasionally vehement arguments to be had: only once all that is settled can we sit back and just worry about the OK equivalent of killer apps, whatever those might turn out to be.

Subscribe to RSS - community