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.

Contrary to popular belief among the developer community, creating patches is not easy for some. Using the text-only interface of the command line is a big hurdle for the more visually oriented. I finally found a way to do this CVS-checkout-and-patching thing without using the command line but through a free app with a graphical user interface.

“…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.

There’s literally thousands of contributed modules out there. If you have forty of those installed on your web site, the user experience will be much improved if the UI for each behaves in consistent ways. We hear developers wouldn’t mind having some advice on how to do this, either.

Over on the Nabuur blog, I've written a short bit about how we're going about redesigning nabuur.com. Specifically about the signup process, how we analysed the existing flow and what we did to simplefy it.

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.

Context: http://www.d7ux.org/structure-summit-sunday

Preamble: The site builder tool is not meant to replace all the available expert interfaces in Drupal core but aims to provide a user friendly get-me-started-quick tool on top of these.

Dit is de eerste 'crowd sourced' usability test voor het Drupal 7 User Experience project.

Wat wordt er getest:

Een eerste opzet voor een taakbalk. Deze taakbalk is één van de concepten die onderzocht worden. Er is een schets voor de indeling van deze taakbalken gemaakt die we graag getest zien worden om te kunnen beoordelen hoe goed de indeling werkt en waar er verbeteringen moeten worden aangebracht.

Download de PDF

Deze test loopt tot eind deze week, tot vrijdag 10 April. Doe mee!

D7UX-usabilitytest-01.pdf