Concepts and tasks - towards a general usability plan for Drupal

Reading the presentation Dries posted on his site (http://buytaert.net/files/usability-testing-minnesota.pdf) I saw a lot of my own thoughts regarding the usability obstacles in Drupal echoed. Thank you all involved for all the efforts that have gone into doing usability research on Drupal. I believe the results we're seeing are invaluable.

I'm posting this as my own reflections on what I've seen and reflected over so far. It's opinion and not statement of fact and I'd like to hear your opinion on the issues I discuss below.

First of all, it is evident there are layers of issues here. Some of these can be addressed by an improved user interface, others must be addressed by better availability of information. I have ideas for solutions to either, as to whether these ideas are workable or feasible remains to be discussed.

Regarding communicating concepts

There are issues at the conceptual level, something I recall facing when I started with Drupal 4.6. Thanks to the patience of and kindness of people in #drupal-support, I managed to get my head around nodes and how you go about building a site in Drupal. I realized what a node was and how content was managed within Drupal but it wasn't clear to me at first looking at the Drupal 4.6 default Pushbutton and trying to make sense of it, wonder where all the information came from and how I changed this and that. Unfortunately it seems people are still struggling with the same problems and here are my thoughts with some suggestions for solutions.

Drupal uses a number of concepts and much of the discussion appears to be about whether we should change these concepts to make them easier to grasp. I fear that doing so brings the risk of making them less powerful. It is my opinion that a better way to go is to become better at teaching users about them.

A comment from the slides was that Drupal made (one or many) of the users feel stupid and it wasn't exactly appreciated. Unfortunately I don't think we can ever prevent that from happening. What we can prevent is making users feel lost, like missing a map and a clear goal in sight. A CMS is an advanced tool and you need to approach Drupal with a little humility.

However, that doesn't mean users should feel embarrassed at not grasping the concepts. The solution to the knowledge problem lies somewhere between educating and simplifying. I fear there's a risk with "dumbing down" something in order to make it more accessible, thresholds should be lowered but cannot be eliminated without loss of meaningfulness. One example can be found in magazines about science. You can compare science as written in its popularized form to what you find if you pick up a copy of Cognitive Linguistics or some other scientific publication. The popularized form is always glossing something over, and if it's poorly written it becomes inaccurate, or even false. Good writers know their readers as well as the subject matter and can communicate the critical concepts in a way that fits in readers conceptual framework. We need to take a similar approach to documenting the powerful features of Drupal, and revealing them at levels at a time. An onion skin approach to documentation if you will.

Further, as the study revealed, such information must be made available, and not on a help page but in context in a way that's convenient to the user. I think existing design patterns can provide us with good examples of in-context help. Hitting F1 should show relevant documentation and if it doesn't exist locally, the handbooks are searched. The user could also click a button to see results from the drupal.org support forums. These are solutions that are relatively easy to implement.

Regarding the interface

Drupal is quite "scatter brained" since to accomplish a task you have to go through a series of steps that requires getting to terms with the technical components of the task or system the task uses. The usability work done show clear examples of how users are required to understand the internals of Drupal in order to use the external interface. A task-oriented interface could very well be the solution to some of these problems.

In order to create a task-oriented interface we first need a good understanding of what tasks users need to carry out in order to build a site. One way to do this is to do more usability studies, of new users as well as experts (in the usability sense of the word) and see what methods the expert uses and how the new users go about learning these methods and where they look for clues. New users will help us understand how to make these powerful methods more accessible, and experts will show us what method we want to model after. Existing site recipes are another source for step-by-step tasks.

We need to be aware that we do not want to stereotype the types of sites you can build with Drupal, running the risk that people fail to see the flexibility of Drupal. We have to cater to the needs of the majority while at the same time not hide the powerful flexibility of our favorite CMS/CMF.

Secondly, I believe we need to focus on abstraction. The modular approach Drupal uses means that tasks are composites, existing of a series of actions involving a number of subsystems very with degrees of interface coherence. By creating an abstraction layer on top, and putting these tasks in a context, turning them into one task instead of many, users do not have to worry about which module provides fields, whether it's CCK or node. A user can just create a new "content type" and add a new "field", in one single task, only having to deal with the abstractions with no need to understand the underlying architecture.

A look at existing design patterns that would enable a task oriented administration panel in Drupal would be a good start. A task oriented administration panel can be built on top of what we already have. I have a couple of ideas for a contributed module that would focus on actions, and would allow users to carry out tasks that normally would take multiple steps and using many different modules and settings screens, in one seamless sequence.

I'm throwing these ideas out here and I'd really like to hear your opinion, whether you agree or not and if we can identify a general direction for improving the usability of Drupal. I've been following the discussions here and there's been a lot of great discussion on separate problem areas. Perhaps it's better to try to get some kind of overview. Either way, these are my two cents and I'll do what I can to contribute towards improving these aspects of Drupal.