Drupal usability

Participants

• Bèr Kessels (organizer)
• Steven Wittens
• Neil Drumm
• Chris Messina
• Dries Buytaert

Here is a first draft of the handouts for the meeting. Unfortunately I have no time to convert any sheets I have into HTML or PDFs yet, so keep an eye on this page, for I will update it when I have better handouts available.

Index and minutes

• Define page-types
• Define content areas of the page-types
• Define content of content-areas with user-cases

• Red marker session.

• Create a list of changeable form-APIs
• Create a list of new form-APIs

• Define all the code-todos

Introduction

The Goal

Have a consensus about the structure of any page in Drupal. Know how any page should look, act and contain. Know where each page should be located.

The deliveries

A list of form-APIs that should be introduced. A list of form-APIs that should be modified. A list of pages and interfaces in Drupal that need immediate attention, in the form of small tasks.

The method:

We should avoid looking at each page or interface and re-design it on a per case method. Drupal is not only too big for that, its mostly too modular to do so. many people have pointed out that Drupals flexibility makes it i,possible to design very specific pages, something Moveable type, or even blogger.com can do. Therefore we must approach this problem bottom up; and so avoid per-case solutions. My idea was to chop up the interfaces, from biggest parts till the smallest parts. We can do this by starting to classify all types of interfaces, then define types of areas on these interface, then proceed with defining actual areas. Then we can define what content such an area can contain; and we end with defining that content. The results of each of these stages are chapters and sub-chapters in our HIG. Once these rules are set, we can go through a set of core-pages and re-design them -with the red marker- to abide these rules. An important issue, is that we must avoid focus on core in the definition of the rules, but that we should keep them valid for any developer. Another important issue, is that we should focus on not only the content of each page-class, but also define its location in the site-structure.

Define page-types

Globaly seen, there are only three types of pages, that can be subdivided:

• browse content
• list of leaves
• (configurable) leaf

browse content, in a website, can be anything, from viewing a node to showing a page from a user. List of leaves shows us a list of objects that can be moderated, edited or administrated. An example is the page where we get an overview of all blocks. A leaf, of configurable leaf is the page where the actual editing, administer, or configure form is rendered. An example is where a node, or a block is administered.

We should refine and discuss this first model.

Define content areas of the page-types

All these page types have areas that can be defined. We should focus on the main area, but should not forget to mention the other, well known areas such as headers, sidebars and footer. When defining areas inside each possible page-type, we will be able to chop up the pages into usable smaller areas, that will and can be filled, by modules, APIs help-hooks and other coding tools like that. By working this way, we preserve usability, while keeping an extreme modularity in mind.

Define content of content-areas with user-cases

Only if we have the areas defined, we can focus on what they can contain. We will do this by first defining four cases of a Drupal site. Then we will divide some important pages over these cases. For example each case will get a node form. But a community site will have to look at a profile page too. The exact pages, types and cases will be shortly discussed before (preferred, on ML or in comments) or during the meeting. The results can then be translated into two things:

• Ideas about what form elements and APIS we still lack
• Possibilities to make mock-ups that can be used as reference for code. Note: can be; a good node-form for a blog might be horrible on a corporate site. But the above-mentioned -and defined- areas should limit us in getting too specific.

Red marker session.

You will all receive a set of screen shots of various (core) Drupal pages. Now that we have agreed upon what pages are '€œallowed'€ to contain, where and how they should appear and most of all, how they should be designed according to our guidelines, we can find all the pages, details etc. that need coding.

Create a list of changeable form-APIs

We should agree upon a set of form_element() functions that need to be re-coded, in order to meet our guidelines.

Create a list of new form-APIs

We should agree upon a set of form_element() functions that should be introduced, to make the life of module developers easier and introduce better consistency. An example could be the introduction of a form_date().

Define all the code-todos

All the previous attempts, guidelines, lists and agreements are nice, but we need concrete results. We need a list of tasks that can go into drupal.orgs issue tracker with all our ideas, improvements and todos in it. So that we, but also other people can take on these issues and code it.