Google is about to conduct a usability study on Drupal to add to previous efforts in this area. This prompted me to put down what I see as the biggest usability problems with Drupal. This is based on the most frequent issues I have to provide support for – both end users and office administrators.
First, contrary to popular perception, Drupal is actually relatively easy to use. For the most part, all you have to do is point somebody at it and they can get on with editing and posting.
But there are some really stupid features that it would be dead easy to fix. I can see the engineers’ need for simplicity and reluctance for redundant features behind some of them but many are probably just a result of code that was put in years ago and has been good enough for anyone to focus on since.
I split my 6 issues into 2 sections. 1-3 cover stuff that’s a problem for end users – the sort of people who register for accounts on a system to access their features. 4-6 cover the sort of stuff that affect the typical office administrator – the sort of person who doesn’t know much about web editing but can do things that are explained to them (often pretty much click by click).
1-5 are easy to fix while 6 is a big one. Most of them have been mentioned before but I have not seen much talk about 1-2 and 4. They are based on my real observations of end users so this suggests to me that there is a big disconnect between the Drupal developer community and the low-tech end user who is likely to come into contact with Drupal’s interfaces more and more often as Drupal extends its reach.
Contents
Problems facing end users
-
Changing the password
This is the most obvious one, so it’s puzzling to me nobody’s fixed it yet. It’s probably because the core developers don’t have to deal with end users who have no technical knowledge.
There’s nothing wrong with the functionality itself but with its position. The change password form is part of the profile editing form. This means that there is no ‘change password’ button users are used to seeing from pretty much every other systen. So we have to tell users what to do to change their password. But that’s not all. Because many modules dump things into the edit profile form, on most sites the user has to scroll down a long way to find the save button, to actually change the password. I have personally observed a number of people typing in a new password and then ask “what next”?
The solution is obvious: Have a separate password changing interface. Or have both, like Moodle 2.0. It works pretty well there and has made our support life much easier.
There is another knockon effect from this decision. When requesting a new password, the one off login link only logs in the user but requires them to take another steps to change it. And they have to do it throught their profile. Instead, it should take them directly to a form where they can change their password and nothing else. I use a lot of web services and I’d say at least 70% of them do it this way. And those that don’t, like Drupal, are just doing it wrong!
2. Usernames v. Realnames
Back in the early days of Drupal and the CMS world, somebody (Dries?) made the enlightened decision that usernames should be allowed spaces. This then led to the conclusion that if people want to use their real name like “John Smith” as their username, they can. No need to ask them to enter personal info. Well, back in 2001, this may have seemed like a good idea. But the world has moved on. Everybody who has used a computer now understands the idea of a username. And they know it’s used to log into systems.
Many people make up funny or incomprehensible usernames. But Drupal (without warning) then uses these to identify them throughout the system whether they comment or post. This is very inconvenient. This can be fixed by the Realnames module but it should be a core feature. Ideally, people should be able to choose how they want to be known throughout the system or add a nickname field. But the username should only be used for login. I know this is redundant but that’s what users expect.
I was caught out by this myself when I signed up on Drupal.org. I picked a username fully expecting it to be asked for a nickname that will be shown to the rest of the Drupal world. But no such luck. And as I said, I sign up for new online services all the time.
3. Save Draft
Unlike the above, this is a problem that I have seen discussed many times before. But it’s still not fixed. The functionality is there – you simply untick the ‘Published’ option under Publishing options. But that requires training. And we have a usability solution that can do this without expending all that time and effort. It’s called [Save draft] and [Publish] buttons. WordPress gets it exactly right – why can’t Drupal?!
Drupal is seeing wider and wider adoption at higher and higher levels. It can save big websites tens or hundreds of thousands of development costs. But I’d guess that this stupid feature has cost millions in support costs across the Drupal install base. All in the name of avoiding redundancy.
Issues facing office-level administrators
4. Comment management
I’ve raised this issue before but got little joy. Imagine a simple site neglected for a couple of months with 100s of comments waiting for moderation. I’ve don’t have to imagine it, I had one. But it simply can’t be done properly in Drupal. There is no one-click option and no proper comment preview. This makes it very difficult to perform bulk operations without missing letting in some bad ones.
WordPress does this perfectly. I’ve been able to deal with the same comment queue that took me almost an hour in Drupal in 10 minutes using WordPress. That’s the main reason why this blog is in WordPress and not Drupal.
5. Internal linking
Here’s another one that WordPress does well (since 3.0, I think, and most commercial CMSs have done for years).
There is no way to link between internal pages without cutting and pasting URLs. That may be a consequence of not shipping with a WYSIWYG but it is truly embarassing. There is a TinyMCE plugin that can do this using Views. But it’s little known, not well suported (at least wasn’t when I tried it), not reliable and not universal enough.
6. Easy content overviews and site sections
So Drupal 7 finally has a Dashboard. But the /admin/content page is still the same as it was in 2005 when I started with Drupal. It can be fixed with Views and the Views Bulk Operations module but there should really be much more out-of-the-box solution.
More importantly, these content overviews should link with a feature that indicates site sections. I know, Drupal has a different content management philosophy than, say, Typo3 and a lot of this could be achieved through Taxonomy and Access but this is not enouch. The typical office level administrator’s expectation is Sections. The Book/Outline module goes a long way but it is not enough. Joomla does this fairly badly but it makes some sense. The ill-fated Category module did it fairly well but had too many other problems.
Unlike the other issues on this list, this may not be an easy one to fix. Drupal with Views and CCK is the most powerful tool for building cool websites. But all that power can be for naught if the people actually using the system can’t find the right things in the right ways.
What’s required for a sustainable solution?
Many of these issues can be (have been) fixed with contributed modules. But the current system of Drupal Core vs. everything else is making this difficult to find a more sustainable systemic solution.
I have long been arguing (in comments on other people’s posts) that Drupal needs not just a “small core” (as proposed by many) but also an “extended core”, a wider list of modules with protected functionality that the community or the Drupal Association would ensure support and development for. These two cores could have different release cycles and different philosophies of backward compatibility. That way Drupal could innovate both on the API level and the user experience level. Otherwise I fear it may face some backlash as its popularity increases.
This could be a way to implement Dries’ distinction between Drupal as platform and Drupal as product. It seems (from discussions occasionally flaring up in the Drupal blogosphere) that both the Platform and the Product have some residual cruft that nobody’s looked at for years. The Platform cruft is well known and I hope to have identified some of the Product cruft here. It seems to me that in the “single core” model of Drupal development, both the Product and Platform parts are holding each other up. The current Drupal release cycle is perhaps a bit too short for Platform but it’s definitely far too long for the Product part. Perhaps, we need something along the lines of the Ubuntu model of Long-term support releases (every 3 years or when ready) and normal releases (every 9-12 months).
All that said, Drupal is still my go-to platform for most websites with any level of complexity. But I find myself recommending WordPress as the starter CMS to more and more people. All it would take is to address at least 1 – 4 of the above problems, I’d be a completely happy Drupal “customer”.