Season of Usability

Status Update

Bevan@drupal.org — Mon, 18 Feb 2008 11:27:32 +0000

With DrupalCon, moving house, and some other factors I have been struggling financially recently and have needed to focus on billable work in order to make ends meet. An influx of urgent client work also contributed to this. Such I haven't found or made time in the last couple of weeks to continue node-form development. This is a status update so that interested parties can keep up with the status of the Season of Usability project.

I will be distributing the 3-month SoU programme over 4 months to counter this and to ensure I will successfully reach my goal of improving node forms in drupal 7.

'Drawers' seem to work well for node-forms, but the idea needs further development and testing in the form of prototypes to see how it can scale with CCK fields and other UI-scalability issues. It will soon be ready for a drupal-7-destined core patch to be rolled.

Not part of node forms but still part of SoU, I put a considerable amount of effort into Views 2 UI which is really paying off with a great Alpha 2 release of Views 2.

Cheers all,
Bevan/

Season of Usability

Update: Prototype on node forms

Bevan@drupal.org — Wed, 23 Jan 2008 13:15:10 +0000

On Monday I started researching recent efforts to date on node forms. There has been a lot of activity in this area recently and things have really taken off this week -- largely pushed by newcomer to the usability group: SteveJB.

To cut a long story short. Consensus was quickly reached that 'vertical tabs' or 'drawers' as we are more affectionately calling them, are probably the best way forward with node forms. They allow a lot of flexibility while not disorientating the user, and providing all the settings, options and other 3rd party fieldsets in quickly accessible areas one click away with little or no scrolling.

I have put together a prototype for default drupal 6 to 'feel' this interface. I have some notes on it where you can join in the discussion.

Season of Usability

Goal decided: Node add edit forms

Bevan@drupal.org — Sun, 13 Jan 2008 08:57:26 +0000

I've been mulling on the ideas for project goals over the weekend and have decided that my goal for the project is:

Improve the usability of node add and edit forms in drupal 7

This is something Chx placed emphasis on in our initial discussion, and Nick Lewis gave 5 very convincing arguments for. Thanks to everyone for your great feedback. I really appreciate it.

Next steps from here:

See how to collaborate with UMN testing (and possibly GHOP) to get more quality usability feedback data and analyses on these forms in their current state in drupal 6
Research previous and current efforts in improving node add and edit forms
Evaluate them and discuss what changes are worth reconsidering for drupal 7
Work with Zoey and Ron (usability mentors) to start working on wireframes for concrete solutions

Season of Usability

Project announcement by OpenUsability

Bevan@drupal.org — Sun, 06 Jan 2008 22:25:13 +0000

Ellen at OpenUsability has announced this SoU project, and I blogged her announcement and some personal notes on CivicAction's blog.

Bevan/

Season of Usability

What are the goals for the project?

Bevan@drupal.org — Fri, 04 Jan 2008 05:54:21 +0000

What are the goals for the project?

Now that the project is ready to go, we need to establish the goals for the project. I have several general ideas. Please suggest more.

General Improvements for Drupal Core (based on results of UMN usability lab testing)
Node-add/edit Forms
Usability Guide/Handbook for Drupal Developers
UI Patterns for Drupal
Managing Many Items With Tables, with;
- links to items and related objects
- data display columns
- operations individual items
- operations on multiple items
- filters
- table headers
- sorts
- pagination
Fix 'local tasks' (Tabs) (Split into, local actions/operations, local navigation)
General Improvements for Selected Contrib Modules; Panels, CCK, Views, Imagecache?

1. General Improvements for Drupal Core

The usability of Drupal core has improved a lot in the last two releases, and there are more improvements coming in d6. However almost all of the usability improvements are small and subtle. The usability and UX (user experience) of drupal as a whole hasn't been studied improved or worked on recently. By this I mean, thinks like workflow, interactive design, page layout:

Workflow

How does a user get from admin page A to admin page B? If a user wants to do a common admin task, can they do it all on one admin page? If not, how many pages do they need to visit, or clicks are required? Is this an acceptable number? How can we make it easier to do these common tasks?

One example of this is module administration. In d6 a user may seek to do many different actions on one or more modules. All of these tasks are spread over several pages in the d6 admin UI:

enable
disable
uninstall
goto settings page
goto help page
check version
find or check dependencies or requirements
check for available updates
go to d.o page

Interactive Design

Now that jQuery is in core and now that users expect pages to be interactive, nice features and usability enhancements like drag-drop block admin and menu admin are getting into core. However AFAICT no-one has considered the more fundamental usability issues on these pages:

A table for block admin isn't the right UI pattern for administering blocks. Does a newbie admin know what a region is? How does the table relate to the layout? Block admin is essentially layout design, and the interface should reflect this.
Does a newbie admin understand that the menu is (possibly) hierarchical? Do they care? Is the flat representation of a hierarchical structure understandable? Is there another representation that is easier to understand, navigate and edit?

Page Layout

Page layout is often overlooked in smaller contributed UI enhancements and features. A new review of all admin page layouts is probably due. Does the layout of each page clearly communicate what tasks a user can do on this page? How does a user know where to find common elements on the page? Do groups of similar pages have consistent layouts?

This work could be based on the results of the lab testing in the University of Minnesota's usability lab. If so, it might be wise to put this project on the backburner until the tests are complete at the end of February, and extending the project out over more time after February.

The goal here would probably be very general.

2. Node-add/edit Forms

There is currently a lot of momentum here within the drupal usability group. There are also a lot of wide-ranging and even conflicting ideas as to how to improve these forms. Given that, I am not sure now is a good time to jump in here.

However it is probably the set of forms that needs the most work in drupal's current state. It is also one of the most difficult forms to work on now, with the level of flexibility required by CCK and the powerful node API.

The goal here could be to provide wireframes for an improved set of node add/edit forms.

3. Usability Guide/Handbook for Drupal Developers

A usability guide for drupal developers was discussed a while back in the usability group. I'm not convinced that a textual, graphical or tabular guide to UI design or UI patterns specific to drupal would be used or valued by drupal developers. However, I do think UI patterns in code, and documented with UI use-cases on api.drupal.org would be useful (See the next idea). Nevertheless this idea is something that could do with more thought or consideration.

A goal could be research and implement a set of pages in the handbook or documentation.

4. UI Patterns for Drupal

There are many great UI pattern libraries available on the internet. Fluid project wiki has a comprehensive list of them:

Welie Design Patterns
Tidwell Design Patterns
Yahoo Design Patterns
Berkeley Design Patterns
Design of Sites Pattern Browser (registration required)
Sakai Design Patterns Library
User Interface Design Patterns
UI-Patterns.com
Oracle Browser Look and Feel Resources
Hypermedia Design Patterns Repository
The Brighton Usability Pattern Collection

(The fluid project is working on an Open Source Design Pattern Library (OSDP) of UI components for web-based software. There has been some discussion about their use and integration with drupal. Currently I don't see how this is technically integratible in a maintainable way, due to drupal's excellent method of abstracting the UI and theme layer of code. I imagine other projects would have similar technical difficulties integrating OSDP code in a maintainable way.)

If a large number of a wide range of UI patterns were easily available in drupal's theme layer and API, drupal programmers and developers would naturally begin to use them. By documenting each pattern's use-cases clearly in api.drupal.org, and encouraging developers to match use-cases to patterns (by using a pattern library in conjunction with api.drupal.org) I hope we would be able to help drupal developers to;

educate themselves about usability, especially in drupal
write better UIs, the first time 'round
cure themselves of fieldset overkill syndrome
create a healthy and sustainable momentum around usability within drupal
conquer the world! ;)

The goal here could be to research and propose a selection of UI patterns for integration into drupal and draw wireframes communicating where and how they should be implemented.

5. Managing Many Items With Tables

It very often occurs in web apps, admin interfaces and web2.0 sites that the user is presented with a large number of items on which they can perform actions (like open, delete, edit), seek more information about, filter, sort or simply view. For example, emails in Gmail, content items in an RSS reader, users in admin/user/user, nodes in admin/content/node, imagecache presets in imagecache.module, adsense color-groups in adsense.module, attachments in a node's edit form, modules in admin/build/modules, themes in admin/build/themes, menu items in admin/build/menu, even links in a menu is a simple form of this UI pattern.

Any time such an interface is presented, there may also be

links to the full view of each item
links to related things (pages, settings, objects) for each item
columns to display additional related data
operations on individual items
operations on multiple items (with checkboxes to select the items to operate on)
related actions (add a new one of these items)
filters
table headers
sorts
pagination

Drupal has APIs for many of the subcomponents of this UI pattern (e.g paginator, tables sorting by table header, actions (like operations), views.module exposed filters), but lacks a consistent API for the more general UI pattern.

Currently drupal makes it more convenient to have all of a contrib module's items' settings on one settings page in fieldsets. If drupal expected contrib modules to need this sort of infrastructure in the module's settings it would help avoid UI blunders like imagecache and adsense modules' settings pages.

The goal here would be to research what is needed in such an API and how to present those elements to the user and draw wireframes communicating the results of that research.

Fix 'local tasks' (Tabs)

Drupal's way of providing an API for adding page-specific actions is through the menu API with menu items called 'local tasks'. From the name 'local tasks', it makes sense to use this API for items like 'add term' on a list of taxonomy terms. The fact that local tasks are menu items and are themed like tabs means that it makes sense to use them as sub-navigation elements like [view admin tasks] 'by module', and 'by type'. However it gets confusing when you have 'save' and 'delete' at the bottom of the screen while 'edit' is at the top.

There is a need to review the UI needs of local tasks, tabs, sub-navigation, actions, and operations in drupal and create a better API that allows drupal developers to have their page-specific buttons links consistently and better placed.

This probably involves;

splitting 'local tasks' into 'tabs' and 'actions'
automatically theming form buttons as 'actions' when the page is a form
theming 'tabs' like 'local tasks'
theming 'actions' to look and behave like buttons -- consistently in all of drupal

The goal here would be to research and discuss the requirements of such an API, put together wireframes for a usable interface for this UI pattern, and put together wireframes for applying this design pattern to some example pages in drupal (like admin/content/node, admin/build/modules).

General Improvements for Selected Contrib Modules

The idea here would be to simply select some contrib modules and create wireframes for a better UI for them. The UI is often very overlooked in contrib, and drastic changes are much easier to integrate into contrib modules which have their own release lifecycle.

Currently I think I'm favoring number 5 "Managing Many Items With Tables", partially integrating number 6 "Fix 'local tasks' (Tabs)" into this, and as part of that look at paving the way for future projects based on numbers 4 "UI Patterns for Drupal" and 1 "General Improvements for Drupal Core".

Number 2 "Node-add/edit Forms" is something I'm still seriously considering.

Please share your thoughts and feedback on my ideas, contribute your own ideas and help my establish more concrete goals for this project. Thanks! :)

Season of Usability

Chx to Mentor Drupal in Season of Usability

Bevan@drupal.org — Mon, 31 Dec 2007 00:01:06 +0000

I'm really happy to announce that Károly Négyesi (aka chx) has offered to be my technical mentor in my Season of Usability project on Drupal. Further Károly also promised to implement the results of the project; "I am making this program better and bigger by promising that I will code whatever you come up with".

Dries also voiced his support for the project; "I'd like to mentor you but I can't make strong commitments -- lack of time is an issue and mentoring people on a personal level is just not scalable for me."

Károly's commitment to the project ensures that the results of the project will bring about useful and positive improvements for usability in Drupal, that the results will be implemented in code and almost certainly get committed. It also means that this project is confirmed and I am ready to get into action!

I will post updates, progress reports, solicit feedback and ask for help on the yet-to-be-moderated Season of Usability group on groups.drupal.org. Please subscribe to the group to get updates and to be involved (I won't cross-post to this blog nor elsewhere). Input and feedback from anyone is always valuable and appreciated.

Thanks once again to everyone who is supporting this and helping to make this possible; Károly, Dries, Zoey, Ron, CivicActions and OpenUsability.

Usability

To Core Developers; I Need You, Please. :)

Bevan@drupal.org — Thu, 20 Dec 2007 22:45:22 +0000

I still haven't been able to establish a technical mentor for my SoU project. I need a Drupal developer with a fair amount of Drupal karma and a small interest in usability, for this project to be successful. I'll be plain; I'm directly asking Dries, core developers, and other similarly-respected folk in the Drupal community, for someone who can commit about 3 hours per week for three months. This is a sizable contribution to Drupal and will result in considerable usability improvements.

Please see http://drupal.geek.nz/node/67 for details.

Usability

Drupal Developer as Mentor Needed for Season of Usability Programme

Bevan@drupal.org — Thu, 06 Dec 2007 23:29:09 +0000

I'm proud to announce that I'm participating in the Season of Usability programme. SoU is similar to Google's Summer of Code, but is sponsored by Open Usability and has a focus on usability, not code, in Free/Libre/Open-Source Software. The goal of my SoU project is to improve the usability of drupal.

As part of the programme I need a technical mentor (a drupal developer) and a usability mentor (usability expert). Mentors help to maintain the direction of the project. Zoey and Ron, information architects at CivicActions, have offered to be the usability mentors. Now I'm seeking a technical mentor. The technical mentor will help to ensure that the results and deliverables will be valuable to the drupal community and integrated into the Drupal project.

Ideally the technical mentor would be someone with a high level of respect within the Drupal community.

The long term goal of this project is not just to improve usability in drupal 6 or 7, but to help build sustainable momentum in the drupal developer community that allows the community to keep drupal usable.

The short term goal of the project will be determined together with the technical mentor. Possibilities include an analysis of the user interfaces in core admin pages and creating wireframes for several pages that need a thorough makeover. Another option is to research, select and design wireframes for UI patterns that can be applied to a range of use-cases in drupal to solve common and problematic usability issues in core and contrib.

The programme will require a few hours per week from each of the mentors for three months starting in January 2008.

Please contact me if you're interested.

Thanks to Open Usability for providing this opportunity, and to CivicActions for co-sponsoring this.

Regards,
Bevan Rudge/

Usability

Usability guide for drupal developers

Bevan@drupal.org — Sun, 25 Nov 2007 22:06:39 +0000

UI-Patterns.com is a great resource for information architects, UX designers, UI specialists, but most of all, for developers!

How can something like this be made more useful and usable by developers of both drupal core and contrib? I would like to see usability start at drupal's roots, rather than being left for an after-thought. (This too-often results in interfaces that are harder to fix than they would have been to get right the first time).

I think a short usability guide specifically for drupal developers would be a big step in that direction. I would like to compose / compile such a 'drupal usability guide', but I'm not sure how such a usability guide can be made usable for drupal developers. Any ideas?

Usability