The slides above are from a core conversation I would have presented in San Fransisco if a certain ash cloud hadn't gotten in the way:
Today we’ll have our 14th edition of UX open hours in IRC. It’s the best way to stay up to date on Drupal UX work and you’re all invited.
We started these bi-weekly meetings in July 2011 as a means for experienced contributors to check in on each others work. But more importantly, these chats are for anybody interested in contributing to a better Drupal UX to introduce themselves and find a good place to cut their teeth.
The University of Minnesota has graciously offered us another opportunity to gather data and insights from observing smart people using Drupal for the first time.
The two lab tests we did with Drupal 6 really brought home the fact that Drupal can be hard to wrap your head around. The community has responded with a drastically reworked Drupal 7 and next week will give us fresh insights on what we improved, what has become worse and which new problems are out there.
If you want to contribute actual changes to the Drupal software, you have to do it through patches. Patches are a kind of text file that describe the changes in a way that lets them easily be applied to the official code base. To create them, you have to jump through a couple of hoops, especially checking out Drupal head from CVS and creating the actual patch from the changes you made.
“…Surgical teams that follow a basic checklist in the operating room, from discussing expected blood loss to confirming the patient's name, reduced the rate of deaths and complications by more than a third.” (source)
Drupal module development will hopefully not cost human lives one way or the other. But when building your module's UI the same principle is at work. It's all too easy to skip the basics, and go straight for the more complex parts of the problem. That’s the interesting part after all.
The modules page is a typical example of a long list that gets hard to manage pretty quick. The categorization is not ideal, with big modules providing their own category and a quickly growing 'misc' section.
The usability tests have shown that after installation, modules do not provide clear starting points to where you can find their configuration pages. Same goes for the new permissions a module might expose. No clear indication that there are new permissions and no clear pointers to where to find them.
Talking for two days straight during Utrecht Ux sprint ruined my voice, but it did accomplish an important thing: Somewhere on Sunday morning, Dries, Mark, Leisa, Bojhan and me finally got to a point that we knew and understood that we were talking about the same thing. And that this thing, the d7ux framework, might actually work, too.
Everybody seemed to have read and understood most of the briefing email and sprint website because there we were, 20+ Drupal peeps showing up at the lovely OneShoe office, on time.
As expected we took an hour or so getting settled, finding team mates, asking for wifi passwords etc. Bojhan ran us through the plan for today and then the teams sat together and started attacking their issues.
Around one hour in we got our first tiny patch committed by Dries. Always good for morale.
Design proposals for D7UX project are starting to show up as code in the issue queue for Drupal core. Actual implementation has started.
To give that effort another big boost, there will be a design and code sprint on the 27th and 28th of june in Utrecht, The Netherlands. We have two goals for this hands-on meeting:
- Get a lot of core patches in for the 80+ silly little usability fails that were found in usability tests. All these little issues amount to a lot of frustration for new users. Lets get these out of the way.