Recent blog posts
Sites that link here
What does it take to make Drupal easy to use?
Dries, the founder and lead developer of Drupal, just posted this on his weblog:
For long I focused, completely and utterly, on the aesthetics of Drupal's code, neglecting eye candy and ease of use. I spent days trying to do something better, with fewer lines of code and more elegant than elsewhere. The aesthetics of Drupal's clean code has attracted many developers, but has also given Drupal the reputation of being developer-centric and hard to use.
--snip--
For Drupal to remain competitive in the future,
- we'll have to offer critical functionality not available in other content management systems, or
- we'll have to make Drupal easier to use and improve the aesthetics of Drupal's user interface design, and
- we have to maintain the aesthetics of Drupal's code.
As other systems are catching up in terms of critical functionality and because the amount of critical functionality is limited, we have little control over (1). Hence, we should focus on (2) and (3). To grow the number of users we should focus on (2) and to grow the number of developers we should focus on (3). Because the ability to make changes to Drupal's code is restricted, we can easily enforce (3). That pretty much leaves us with (2) to worry about
First reaction after reading this: Yes! Yes! Yes! (and more yes!)
Second reaction: Ok, but how?
The potential for Drupal's success on the web is staggering. If Drupal can rock all three: offer all critical functionality in an easy to use package built on a beautifully constructed and extensible framework - it will compete on a level no web-platform currently can.
But #2 seems to be the sticking point. For every message that goes by on the developers list or every CVS commit what percentage come from someone with training in usability? For every thought or effort that goes into building a new feature, what goes into trying to make sure someone can figure out how to use it?
Very succesful consumer mass market organicaly grown open-source applications are extremely few and far between. Heck, maybe they don't even even exist yet come to think of it. Firefox is just now nearing 10% market share, and they've had helping hands with pretty deep pockets since the start. Wordpress has big install base, but their blogtool market share is a relatively small slice so far, and their slice of all internet publishing tools is vastly smaller.
But more troubling, both these applications are - relative to drupal - in much more well defined application spaces. By the time FireFox came around browsers had been used for 10 years. Likewise, when WordPress was started blogging tools were well understood and are pretty straight forward and simple applications. But Drupal is off the map - innovating on many fronts at once. For code development this works out ok, developers simply adhere to Dries's oversight or their code doesn't get checked in. But for making the interfaces easy to use and aesthetically pleasing? That is hard work I don't think the Drupal community has the expertise to pull off currently.
But we certainly can get a lot farther along than we are right now. The before and after photos are impressive, Drupal has come a long way in a fairly short amount of time. Dries' consistant insight has gotten Drupal to where it is today. Just as Blake Ross' commitment to making a browser for his grandma turned Mozilla into FireFox and Matt's comitment to aesthetics and usability made WordPress into a work of art, Dries' commitment to making Drupal usable is a pre-requisite for what it takes to transition Drupal from a powerful gadget into a pervasive utility.
But Dries is going to need a lot of assistance. How can we help?
Here are some options that I see...
- Rally the troops: consistantly press on Drupal developers to contribute interface and usability improvements. Make it a chief objective of each point release. Dries is already doing quite a bit of this.
- Find allies: figure out a process for better integrating outside usability oversight and go find usability experts to contribute back to drupal pro-bono. Kieran is pursuing this.
- Hire mercanaries: go raise money to employee usability experts and interface engineers to reshape Drupal's interface. I will soon be in a position to pursue this.
- Clone Steven Wittens en masse: any takers?
Comments
Evaluating and fixing the
Evaluating and fixing the problems efficiently does require some usability and design skills, but I'd be wary of anyone calling themselves an "expert". If they have enough experience, they may be able to give you some advice based on inspection, but any expertise on the usability of your tools can only come from analysis of data gleaned from observing people using them.
Create content
Look at Joomla and Wordpress. They do a terrific job. Once you've installed everything you're invited to create content and users right away. It's so easy. Then you manage content and users. Perhaps modules. Imagine if Drupal could ever become as easy to use. Once installed you could create a page or a story with a couple of pics - just like that. I've been using Drupal for 4 months - and I still lokk just about everywhere whenever I need to adjust the setting of my FCKeditor.
Measuring It...
I think that is really all it comes down to. We'll never know if its usable unless we find a way to measure it. Some statistical graphing modules released in 4.7, in addition to enhanced tracking of link click throughs... say for example, logging how many clicks a menu in a certain block gets, or how many times a menu item is clicked. There would be overhead for something like that, but the idea is to be able to see fingerprints of users on the site... While I doubt we'd be successful in harvesting the data from very many users, I think some real insight could come from people who used such a system on a high traffic website.
Ramble, ramble....
Hmmm...
Do you really think we can code our way out of a usability problem? :)
not at all...
The idea is to write code that uses the wealth of data that drupal sites already log, code modules that extend statistical tracking. The reason I feel this is important is that the most successful interfaces usually go through formal experiements complete with control groups, and dependent and independent variables. The process is always slow, but the result is almost always a successful website. However, the practical barrier to doing that kind of research is -- well -- funding.
So yes, in one way we'd be coding ourselves out of the problem. But we wouldn't be developing a new interface, rather we'd be developing a set of tools to help us better understand what works and what doesn't in live sites.
At the very least, I think the thought is worth consideration. Especially when the only alternatives are as reliable as the advice from a psychic (::puts hand over third eye:: "I see people finding this form usable" )...
I do think it's a good idea, but...
(sorry for the snippy reply above)
I think fundamentally what we are confronted with is a usability problem and we are best served by approaching it from the perspective of usability practices. Control groups, testing, data (such as this tool would provide) are a major component of this of course, but they are a means to an end - tools - not a solution.
So what is the solution?
Well....
Snippy? Hardly... those kinds of response are good for online conversations. The trick seems to be to retort in such a manner as the other has no choice but to respond and defend themselves... Also, I have no emotional attachment to this idea. As a matter of fact, I am bit skeptical myself. As a matter of fact, I'm kind of testing it on you. My skepticism in has increased, btw.
--0--
I agree, the problem is that certain parts of drupal's interface are interferring with people's ability to take full advantage of it. Its important that we seperate usability problems that exist in the vanilla CS, or drupal, and usability problems which pop up in live, so called "production" sites with an active community. One could argue that problems on those sites are not our business and the fault of the "inexperienced" designer. But I think that is foolish; clearly, the platform somehow contributes to the absolute plethora of badly designed drupal sites....
In regards to developing ways to measure user activity (or lack of), we'd be giving individual users a powerful tool to measure, experiement with a new layout, or organization, and measure again. It takes time, but with patience, and disipline, that kind of approach to a website can pay off big time. Your design becomes a science, instead of Ms. Cleo saying, "ya mon, I be seeing many users understanding this here navigation SYStem." I mean let's be real, since typically, we decided that an interface is good on a gut feeling, because some other guy said "that's good usability", (or often because we're damn tired of messing with it, and are on deadlines)but, for me at least, the total lack of evidence for such hunches, or the so called advice of experts leads me to believe that the majority of so called usability is no better than witchcraft. I think over the long term, a module that was built to assist in small usability studies and experiements on websites could provide an unprecedented amount of understanding to what actually occures when Joe A Random visits a drupal site, and registers for an account. In reference to an earlier comment, I guess my underlying assumption is less of code saving us, as science saving us.
---+0+-----
There are obvious ways we can make the vanilla system smoother:
1. More AJAX -- and yes, I almost burned myself with that buzzword. But seriously, I think page refreshes are Drupal Public Enemy Number One. AJAX is an early answer to smoothing that out. Little improvements in 4.7 like being able to upload, and see files in the node submission form without previewing, or submitting the node make a big difference. They seem little, but I've seen new users mess up uploads because they forgot to submit or preview the page. And I mean, this always screws up new users -- its profound, but part of the drupal learning curve is understanding that most everythign has to go through a submit button. It seems like a gee-duh-[drool] sort of concept, but I think we forget how little most people care about the internet, much less "user interface", and how to interact with dynamic websites.
That same mistake tends to carry over to block settings (again, they have to press submit and check), menus, categories, comments, o - god - the list can go on and on where ajax could smooth out the process. I know, that's really shitty suggestion A) because its obvious, B) who is going to spend time and money coding it? Certainly not me, I'm already behind enough on some deadlines for CS sites!!
However, I guess that's the point -- time, resources, and the state of the internet make most of the obvious solutions only doable in the long term, and with considerable cost in terms of effort.
The real issue for me is whether logging user activity through menus, and pages would actually reveal data that could be useful for a usability study. I think it could, but I wish I had an expert on hand to tell me I was full of fecal droppings, or "hmm... I think it might be possible".
I think the module would be relatively easy to build using, and extending existing modules, and that it could provide a needed tool that helps the community help itself, and gain knowledge that would never had existed had we not made it easy to conduct such studies....
That's my other ulterior motive, I'm thinking of building the sucker, and have an idea on how I'd go about it, but I have an interest in not building a module equivolent of Consignia. And I drink far too much coffee.
Hmmm...
Approaching this module as a fundraiser, there are a few things I see that would get in the way of getting this module built...
Pitch for guerilla UE
Trying to solve a usability problem in existing code by writing more code? That sounds to me like having a hammer, and every problem looking like a nail. In my experience, usability problems are best approached by watching people as they try to use your tools do their work, preferably in their native habitat. There are a number of ethnographic techniques to employ, such as contextual inquiry, which need not require extra funding. Evaluating and fixing the problems efficiently does require some usability and design skills, but I'd be wary of anyone calling themselves an "expert". If they have enough experience, they may be able to give you some advice based on inspection, but any expertise on the usability of your tools can only come from analysis of data gleaned from observing people using them. There can be value in more structured test environments, instrumented code, etc., but that is a more advanced and far most costly route, not the place to start.
BTW, I just started trying to use Drupal yesterday, so I have some initial sense of the enormity of the problem you're talking about.