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! :)
Comments
I'm not sure if it was clear
I'm not sure if it was clear here:
I need feedback in order to make a decision about the goals of the project. I'm very unsure which goals are appropriate realistic and doable.
Once we've collected some thoughts and initial feedback I'd like to discuss them on a phone call with chx and other drupal developers and make a decision.
Thanks! :)
Bevan/
I would say
Start with
1. General Improvements for Drupal Core
Then approach
5. Managing Many Items With Tables by starting 7. General Improvements for Selected Contrib Modules with looking at Views, which we all want headed for core to take over those admin and other lists. See Views Node Operations.
Meanwhile, think about and do some work on
4. UI Patterns for Drupal and 3. Usability Guide/Handbook for Drupal Developers -- these will be far better written after you've been working on real issues and have actual use cases, and you can skip any recommendations that don't even resonate with you.
Finally...
Help complete work, if necessary, on 2. Node add/edit forms and 6. Fix 'local tasks' (Tabs) -- these I really think are connected, and one thing that I think is important is that people now expect tabs to automatically save work between them-- for instance editing different sections of a user profile is a usability nightmare of accidentally failing to save one tab before going to the next. That requires an important UI change, there should be a clear visual delineation between tabs that will all be part of one form with magic javascript and links that take you away from a form.
I know I listed everything, but that's my two cents on priority-- 4. and 3. shouldn't be large, glossy documents that maybe nobody uses, they should be the distillation of your experience. And the way I see the connections it's an overview of Drupal core first (a standard way to provide links between related administration screens would be a great start, for example so people can go to theme settings to turn off "Submitted by" for a given content type after editing a content type -- in this case I think it should be editable in both places, but a link would be a start.) Then the table/listing issue is best approached by working with Views and related modules in contrib, and helping pave the path to core. Let others do the heavy lifting on tabs and node add/edit but do try to weigh in with suggestions. And the byproduct of all this should be documented best practices and some recommendations for developers, possibly including selected UI design patterns.
But you know best! Good luck on this large and important project!
benjamin, Agaric Design Collective
benjamin, agaric
OK this is what I thought
OK this is what I thought when I read it, don't know how much would actually be helpful:
Block admin - I think this will eventually be solved best by panels 2. Quite possibly not until D8 but it looks pitched to replace block.module (and regions) altogether.
A big issue I find is the disparity between cck fields and other modules in terms of how that interact with the form. I much prefer the way CCK deals with this (although that ui in itself has a way to go). When you have a few cck fields, multiple taxonomy vocabs, ui nightmares like Location it gets crazy in there.
Definitely do this last, and if 4. takes the form of code style it'll probably be much more effective than documentation.
This is a biggie, but it's going to get ever more noticeable with drag and drop since ironically it exposes ui inconsistencies by making them more consistent. One big issue with D6 drag and drop is it doesn't yet work across pages, so requires a fallback to individual item edit to get around that. There's also a few places that don't have multiple operations, but probably should have (taxonomy terms again, path aliases(!)) if there's a general tidy up.
tabs/local tasks - oooh yes please. Quite a big change in terms of the menu/forms system, but you have chx :)
I pretty much agree with Benjamin in terms of priority.
Better documentation + Theme info
For example in /project/cck there is
Resources
Read documentation
But his is not a required element for all projects. The code that generates the project pages should require that this field be present. The number of projects that I can't figure out without reading the code is way too high.
A few guidelines for its content would be nice, e.g. what settings need to be made to make it work.
A demo would be nice for lots of the modules.
-----------
I love the code that tells me about my modules that now have an update available. Similar information about Themes would be nice. I use a modified version of Zen and recently accidentally found out that there are updates (some of which fix issues I have seen).
For me there isn't any
For me there isn't any question -- its the node forms. There's five reasons:
1. Usability improvements in that area would benefit the widest spectrum of users. I can't think of a single page in drupal where the user experience is more important.
2. The student has plenty of sources of inspiration, be it Microsoft live writer, wordpress, blogger, or the work of any number of giant corporations who've already implemented UI patterns based on 100's of hours of usability research.
3. Its a small enough task that the student has a chance to do it very, very well. A small task done well is worth 10 large tasks done half-assed, or incomplete. This is small enough that it could survive the gauntlet of code review.
4. Its an opportunity for the student to make a lasting mark on drupal that will be felt for years down the road. Hell -- do a good job on this task, and you've just earned yourself enough reputation to start your career in drupal.
5. The task is the most straightforward. The rest feel like they'll require a lot of work for a comparatively small impact (data sorting), or they'd require a level of editorial discretion that we can't assume they'll have (ui guidelines, and patterns).
As a final note, I think the node form serves as an ideal point to connect all those myriad admin settings that you mentioned in task idea no.1. The node forms should be done in the spirit of task no 1, no doubt.
My two cents.
"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
Work: http://www.onnetworks.com
blog: http://www.nicklewis.org
"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org
Your 5 reasons are all very
Your 5 reasons are all very good and very convincing. Seriously.
A couple of clarifications; the SoU programme doesn't normally involve implementing (in code) the recommended UI changes or results of the project. Normally in a SoU project the community and/or technical mentor do that. For this project Chx has said he will code the results of the project! :) So we need not worry here. This allows me to focus 100% on the usability issues and tasks at hand and not concern myself with the details of the implementation. However I need Chx and the drupal developer community to make sure I'm staying on track and that what I'm doing is in fact implementable.
I already have a 'career in drupal'. I'm a themer and engineer at CivicActions. In fact I don't think I could do this project without their (and OpenUsability's) support. http://www.civicactions.com/team/bevan_rudge
Through this project I'm looking to gain experience in usability, possibly do more of that professionally (and less programming?), and give back to the community and project.
Bevan/
I think #1 if possible - but...
Bevan,
The tems you mention in #1 would
a) Be a good foundation for future work
b) produce actionable coding projects for developers and administration specific theme developers (i.e. a killer admin theme)
But - as with many such projects - specificity rules. The more specific the objectives are the more likely the project gets a green light. And since #1 is rather general (by your own admission) it may not be a go. And you may find that there is just "too much" to do there.
If that is the case - you could choose to tackle administration workflow specifically. I think there would be sufficient material in that subject alone. As a long time Drupal user I still find it hard to remember where certain administrative tasks are (so much so that there are times when I know its quicker for me to make a change in the database directly without even bothering to look at the admin interface.)
Failing that I would then look to #5. Once again sufficient material to tackle for your project. What I like about that is that it IS such a common UI pattern that you could educate Drupal developers and get them to start thinking in UI patterns starting with this common one. Then future usability work would benefit from this education - and this one would have a major impact across SO MANY modules that it would prove to be a huge improvement in Drupal.
Oddly enough #3 - Node Add / Node Edit is probably the easiest to use component in Drupal. What a lot of people forget is that most users of content adding and editing form are NOT admins. They are presented with the FULLY BLOATED interface that the 'admin' user sees. And if a Node form is complicated that is the fault of the site administrator and/or the themer, but not very likely a problem with Drupal itself. Granted, some CCK fields could be improved but that's more a project on how to educate CCK field developers on creating a usable field.
When working on the usability report I wrote up a couple of years ago I got a lot of anecdotal feedback from users saying that adding/editing content (without uploads) was 'easy'. They got it straight away. They found nothing confusing even when given taxonomy fields.
If a node entry form is complicated I would bet dollars to doughnuts its because the creators of the site have not thought through thoroughly enough what it is that users are supposed to DO when they are presented with that form. i.e. They really have not thought through their information architecture - and they haven't done their jobs creating the right content types for the site they have. If the IA is right and the content types match the IA and each content type is exactly right for the type of content the user is adding/editing then there isn't a problem.
But now I am ranting....
So - I'd say #1 and specifically Administration workflows - OR #5
andre
Thanks for your thoughts
Thanks for your thoughts Andre.
This is very interesting. It points to the too-many-options syndrome found in much floss-ware. However this same flexibility is drupal's biggest asset and I think some classic usability rules must be bent for drupal on this point.
Bevan/
Node Form Musings, etc
Hi Bevan,
From my experience, there are different types of clients and their usability needs vary greatly. Here are the top 3 I can think of:
Admins
People who do things like blocks / menus and settings.
Goals: Making their learning faster and their work faster and empowering them to figure it out themselves without causing havok.
Content Editors
People who work for an organization and mainly create posts.
Goals: Make the node edit for easy to digest, improve WYSWYG support, make taxonomy / placing the content on the site more intuitive.
Community
People who come to the site to do something and may never come back
Goals: razor sharp reduction so they can see only exactly what they need to see and it's dead simple and in plain language (0 training).
Here are my top 3 wishlists for each group:
Admins
Editors
Community
hth,
Jacob
Personas
Drupal personas are at http://groups.drupal.org/node/3761
I have decided on the goal
I have decided on the goal for the project: http://groups.drupal.org/node/8143
Bevan/