A few things recently have prompted me to think about the difference between how we pursue the goals of usability and the goals of good software development. In particular, how do we deal with the fact that the mindsets of professionals in both disciplines are often different?
The main prompt was this post by Larry Garfield. He’s a long-time Drupal contributor and his lengthy post covers various topics, including the Drupal ‘smallcore’ movement and the D7UX project designed to improve usability in the upcoming Drupal 7 release.
His first major point is a criticism of the way ‘smallcore’ if often discussed, arguing that the focus on ‘smallness’ is misleading as the true goal should be flexibility. I agree with this, but this post isn’t about smallcore, so I’ll leave it at that. What’s important about this observation is that, amongst software developers, there’s a great concern to avoid making software that is ‘bloated’ or ‘inflexible’. There’s barely any disagreement about this topic: given that a piece of software like Drupal must serve as a platform for many other developments, it’s necessary that it maintains the capability to be customised for many different purposes.
What follows in Larry’s post is a discussion of the different philosophical approaches one might take to build a flexible CMS/framework. This is the sort of debate that occurs very often in software development. There are hundreds of books, each of which running into hundreds of pages, detailing different philosophical approaches to building software. Each concept for software design is expanded upon until, eventually, we have so many competing concepts that it becomes necessary to create yet another conceptual model that attempts to go ‘back to basics’ and simplify things (I’d argue that Domain Driven Design is an attempt to take Object-Oriented Programming back to its roots, for example).
My point is that software developers are always seeking for a way of building software that is simple, elegant and definitive. We never quite find one that we’re happy with, but what we’re looking for is a system that reduces – or eliminates – the need for repetitive work. Software developers are lazy – and that’s why they’re good at their jobs. Software should be as complex as necessary and as simple as possible. Keep it simple, stupid, and don’t repeat yourself. Simple, reusable software can be tested for bugs once and re-used many times without that expensive effort having to be repeated. When we want to change something, we change it in one place and the same change automatically applies elsewhere. A lot of effort goes into making things that simple.
This brings me on to the second part of Larry’s post, about the Drupal 7 User Experience project (D7UX). This is intended to improve the usability of Drupal, a very necessary aim as Drupal is now competing on many fronts with both corporate enterprise software and lightweight, single-purpose content management software.
Tellingly, Larry’s criticism of the D7UX project is this:
The D7UX project was focused on a particular class of CMS, and most of the code that came out of it was in the form of large single-purpose Lego blocks.
In other words, the usability improvements made were insufficiently re-usable, too focused on solving narrow problems. Given how developers think, these conclusions are not surprising. Larry links to Leisa Reichelt, the usability lead on the D7UX project, who concludes that:
From the very outset our goal with D7UX was to make Drupal more accessible to people outside of the Drupal community and less technical people – people who didn’t even know what PHP was let alone how to code it. … This approach is representative of the goal to make Drupal more of a ‘product’ – an out of the box CMS solution that non-technical users can drive. … The changes that are required to the interface to really achieve the goal that we were tasked with … has the consequence of making Drupal a less efficient and enjoyable place for Drupal developers to build cool stuff. … And so we have this tension. Drupal as a ‘Consumer Product’ and Drupal as a ‘Developer Framework’. Currently, the official direction is that the project is going to attempt to be both. I think this is a serious problem.
I think that this is the classic technology vs. usability problem. Developers want to create things that solve a wide range of problems at once, including problems we don’t even know that we have yet. Usability professionals think more in terms of concrete use cases and user personas. Getting the two sides to agree about how a piece of software like Drupal should work is very difficult. Larry quotes a discussion:
Bojhan, one of our two new UX leads (woohoo!), commented:Yet in most discussions, developers assume that design proposals are ill-informed – even if the design proposals truly are informed (by user observations and knowledge about Drupal inner workings)To which Jeff Eaton replied:And designers, in most discussions, assume that developers are visually illiterate and uneducated about UX matters. It’s a double-edged sword.
In January this year I gave a presentation to Northern User Experience about the different approaches that developers and UX people bring to their roles. For me, the difference boils down to the fact that UX people think in specifics, and developers think in the abstract. The D7UX project seems to have suffered from some of the problems I outlined, with misunderstanding and suspicion creeping in as both sides struggle to understand the other’s aims.
So what’s the solution? Personally, I think that Leisa Reichelt is correct, that it is likely to be impossible to reconcile the needs of all of Drupal’s user groups in a single project. My perspective on this comes from working at PRWD, as a software developer at a usability-led company. I’ve learned a tremendous respect for usability, but it’s important to remember that usability means thinking in specifics. It’s impossible for a single centrally-run project to consider all of the specific scenarios in which Drupal might be deployed, or even to identify a very common use case.
What would be better would be to accept that Drupal is never going to be an off-the-shelf product. This does not have to mean the end of the ambition for Drupal to be everywhere on the web. Larry makes an analogy with Firefox, but my analogy is with Linux: there is a core of software called the ‘Linux kernel’ which is used in thousands of high-powered web servers, data-crunching applications and supercomputers, but is also used on Netbooks and even mobile phones. It would be wrong to call Linux a ‘product’, because nobody uses ‘pure’ Linux. Ubuntu, Fedora, CentOS and Slackware are products that people use. Some of these Linux distributions are built on top of each other – Ubuntu is based on Debian, for example. Ubuntu is friendlier and easier to use, but it still wouldn’t exist without Debian. Likewise, we’re going to have to build new distributions of Drupal and that is the correct level on which to consider usability. Development Seed have produced a great example of this with their OpenAtrium intranet software – it’s built on Drupal, but the user experience is far better than an out-of-the-box Drupal installation. And the reason that it is better is that it has been designed for intranet use. Those same usability improvements wouldn’t work for a Drupal e-commerce site, or a Drupal social network.
As strong as the Drupal brand is, I think that the future might consist of separately-branded products targeting Drupal at specific use cases. The underlying framework will be the same, and that framework will ensure module compatibility across different distributions. But usability, apart from the most generic of usability considerations, will be the responsibility of these different products to consider.