Drupal usability tests from the University of Baltimore with community solutions
Download reportWatch the video
The Interaction Design and Information Architecture program at the University of Baltimore and a team of eight graduate students in the Research Methods class, taught by professor Kathryn Summers, have completed a usability study on Drupal. The Drupal community has been working with Becca Scollan in the usability group.
The usability research used video recordings and eye tracking tools to follow participants gaze in the Drupal interface. The study used eight participants, which is considered a valid sample. The study duplicated some tests done in usability testing at the University of Minnesota, and confirmed several results.
Fixing the usability problems
Core issues from both studies
- WYSIWYG in core: WYSIWYG group, Better input format support in Drupal 7
- Evaluators said that "content" was used too often in too many contexts and that was confusing: content, post, node , Change "story" content type to "article" or "news", Content types descriptions tweaks
- Distinguish administration areas of Drupal and content areas: Rethinking /admin, Admin dashboard, Admin theme
- Several evaluators wanted a step by step instruction on how to start: First steps out of the box , Help API, including discussion about tutorials, Burn the help manual a strategy for self explaining UX
- Evaluators successfully added content but didn't recognize it had been created: Node administration
- Evaluators confused that help about administration was on the homepage and expected administration information on the homepage: Help API, Burn the Help Manual video.
- Evaluators said "I'm not sure what a 'teaser' is."
- An evaluator created a new block, but didn't notice what had been created or other changes associate with the block: Preview feature for blocks
Content type creation problems from UMN study
- Evaluators clicked on "Post Settings" expecting to find field additions: Improve understanding of add new fields
- Several Evaluators never clicked the "add field" link, but clicked every other link: Move fields to top level in Content Management, Improve messages when there are no fields available or enabled
- Evaluators thought that content type was a field that could be added to a page: Fields in core
- Evaluators navigated to the "Site Building" page to start the process: some of this is fixed in D7, move content types and forums into site building, rework admin categories
- Evaluators were confused by grouping of radio buttons on the Content Field page: Remove nested fieldsets on add field form
- Evaluators expected "Access Control" to be within the "Content Type" menu: Split access rules into an optional module