Articles

This article takes a look at the importance of designing user interfaces from the outside – i.e. from the users’ point of view – rather than from the inside out. To illustrate the point, we examine the user interface creation system for the Drupal open source content management system.

Introduction - The 'Bad' Old Days

Before I became involved in usability work, I designed and built special effects features for several releases of CorelDraw.

<confession>Shhh! Don't tell anyone, but back then I really didn't pay much attention to user interface design at all! To be honest, maybe I even felt it got in the way of what I wanted to do – which was make code for cool effects! </confession>

For CorelDraw version 3, I invented and built a feature called 'Blend on a Path' and I built a big dialog box to hold all the widgets for making some really cool effects. I woke up to the importance of usability with a bit of a jolt after a colleague looked over my shoulder and said :

"Holy Crap! That looks like the control panel for a 747!"

And he was right. I don't have screen shots of that original travesty but it looked something like this:

 
So I changed direction and reworked the dialog box to create a significantly more compact and organized dialog box:

 
Here's the simple but significant difference: the first dialog box was just a collection of controls that were required to capture the power and flexibility of the new features. The revised dialog was more intentionally designed for usability. Where the first dialog box lasted about a day, the ‘intentionally' designed version has survived for 10 generations of CorelDraw in more or less the same format (besides new icons, the only perceivable change is that dialog box is now ‘docked' rather than floating.)

Intentional Design is Critical

Designing a user interface intentionally is critical to achieving usability. Intentional user interface design is what comes directly out of a process of organizing and laying out the pieces of an interface in ways that will make sense for a target end user.

I don't want to get into the infinite ways we could interpret the words ‘make sense'. I want to point out the significantly usability cost of having a user interface take shape through a completely non-intentional method.

And that brings me to the administrative user interface for the Drupal content management system.

Drupal's Non-Intentional Interface Production System

As a software engineer I have enormous respect for the flexibility and power that Drupal's architecture provides. Likewise I have enormous respect for the many contributors who volunteer their time to build this open source platform.

As a usability engineer I have to view Drupal as being very much in its infancy with regard to its administrative interface. I'm certainly not the first person to say this. There are many in the Drupal community who are actively looking at ways to make the user experience less stressful and more productive.

Talking about usability design is like talking about music. Basically everybody has their own taste and preferences. Personally, I'm not interested in trading opinions about "what's best" because that discussion will never end and it will never get anywhere. For my part I want to look at it in terms of the systemic root causes of poor usability. Such an analysis can lay a solid foundation for devising a systematic solution that can address the full scope of needs and requirements.

I believe Drupal's administrative user interface suffers from poor usability because of its complete absence of a mechanism to capture an intentional user interface design. In other words, the standard practice for creating administrative interfaces in Drupal does not provide a way to design the interface from the outside and connect the intentional, user facing elements to the functional back end.

So how are user interfaces created in Drupal? Basically, from the inside out, at the code level. Here's a snippet from the ‘Views' module:

if ($items) {
   $output = theme('table', array(t('View'), t('Title'), t('Description'), t('Provides'), t('URL'), t('Actions')), $items, array("cellpadding" => "4"), t('Existing Views'));
   $output .= theme('pager', NULL, $numViews);
}
else {
   $output .= t('<p>No views have currently been defined.</p>');
}

This won't mean much to anyone who isn't a Drupal developer, but the point to underline here is that it is in such a code oriented context that the developer must make decisions about what goes into a user interface. Rather than being able to visually placing the controls in sensible places the developer must rely on textual cues to send messages about usage to the outside world. All those bits that look like t('Title') and t('Existing Views') and t('<p>No views have currently been defined.</p>') are how the developer communicates to the user about how the interface works. It's a classic inside-out approach.

The Views module itself is a critical component in Drupal's suite of powerful tools. It provides a way to pull things out of the database without having to write horrendous SQL queries such as this:

SELECT node.nid FROM {node} node 
LEFT JOIN {term_node} term_node ON node.nid = term_node.nid
LEFT JOIN {term_hierarchy} term_hierarchy ON term_node.tid = term_hierarchy.tid
LEFT JOIN {term_data} term_data ON term_node.tid = term_data.tid
WHERE (term_node.tid IN ('42','87','59')) AND (term_data.name = 'data118')

Hats off to the author of the Views module for saving us from having to work with the likes of that!

The difficulty is that developers who write new features for Drupal (i.e. new modules) are basically tied to the inside-out way of building user interfaces. Within Drupal's standard or optional components there is no alternative method that would allow a user interface to be built from the outside and then hooked up to the back end. Building an alternative would be a sizeable task and, within Drupal's volunteer community, it's not likely that anyone has the resources to bridge that gap.

Developers are the folks who are tasked with the role of ‘transporting' users through unfamiliar territory through the vehicle of a user interface. In Drupal's case module developers guide administrative users and even other developers through the maze of options and features that allow Drupal's power and flexibility to be put to use in configuring a web site.

The problem is that the  lack of an intentional user interface design mechanism forces developers to essentially code ‘blind'. With the ‘taxi drivers' blindfolded, the usability quickly hits a wall and the administrative user get tossed through the windshield.

The Great Wall of Non-Usability

To illustrate my point I'm posting a screen shot composite of the fully expanded Drupal Views administrative interface below. This is just one segment of the Great Wall of Non-Usability that administrative users encounter. For scale, I've added a copy of my old blend dialog next to it. See if you can find it:

The result for newcomers is not so much a steep learning curve as a virtually insurmountable learning cliff. Using such interfaces is about as joyful an experience as filling out a tax return.

To be more accurate, the form isn't fully expanded like that when you first encounter it. Drupal's interface system allows controls to be grouped into ‘collapsible fieldsets' which means vast amounts of it are initially hidden from view. This saves space but of course it makes the task of finding things significantly harder.

Speaking from personal experience it took me, a technically proficient individual, many months of intense effort to get over this hurdle. Much of that time was taken up with simply searching through the interface looking for clues about where the necessary pieces might be kept.

End User Impact

The difficulties inherent in the non-intentional system of user interface construction prevent the full power of Drupal from being exploited efficiently. The usability issues quickly trickle down from site developers to site administrators and then to content managers.

Ultimately it can affect the site end users, even though they typically would never be exposed to any of the administrative interface, because a content management system that is difficult to use will impede the flow of timely delivery of quality content. I have recently done some research in the area of Drupal based library systems that seems to confirm this.

In Search of a Solution

As I mentioned, many people within the Drupal community have become (painfully) aware of this problem and are actively working on solutions to correct it. For my part I love difficult problems like this and my associate William Roboly and I intend to pitch in with some efforts of our own.

I think it's important to keep two things in mind:

• the power and flexibility of Drupal make these efforts completely worthwhile
• it is a normal (or at least typical) stage of software systems evolution to have the power and flexibility developments precede the usability maturation

Long ago, when I was building that new, improved blend feature, I went through the same phases. The difference is that the development environment I was using at the time had a system of creating an intentional user interface. It was far from a WYSIWYG interface design tool (Microsoft's Visual Studio didn't arrive on the scene for a couple of years after that) but there was a means by which I could conceive of an interface from the outside and then go and build it.

The lack of an intentional design system is the biggest challenge to anyone who seeks to improve the usability of Drupal's administrative interface. It will require some pretty deep thinking to fully understand the extent of this systematic problem and then arrive at a powerful and flexible solution.