design for style


Drupalcon day one notes


Notes from two of the sessions I attended today. I also wrote some notes by hand, as I was conserving battery power. They're not represented here, and didn't accrue as many notes from me - and definitely aren't as organized. Those sessions were: Walkah's OpenID presentation, and Earl Miles' Nodequeue 2 and Panels 2 demo.

Also, Dries' keynote was inspiring, with a vision of Drupal as an RDF platform where the field is the primary honored bit of data (not the node), and data is contextualized and made meaningful using a subject - predicate - object model, and can be queried using SPARQL. Real "wow" type stuff.

I've committed myself to doing some write ups for the newsletter, so you may see some of this later in a more prosaic form:


Cody Hanson (U of M)
Chad Fennell (U of M)
Angie Byron
Nathaniel Catchpole
Greg Knaddison
Neil Drumm
Karen Stevenson
Bevan Rudge(?)
Kieran Lal
- lots of data posted there

Cody Hanson and Chad Fennell:
Why formal usability testing?
- None of us can unlearn how to use Drupal.  We know what a node is, what an input format is, etc.
- People who care about it most can't use it for the first time again.

What to test?
- Drupal is highly customizable - what to test that will be the most relevant.
  - Drupal 6 w/ CCK, taxonomy, menus, blocks
  - hard to avoid terminlogy that appears in the inferface, when crafting tasks
- Personas
  - visitor (anon)
  - content
  - site maintainer (<- narrowed test to this gropu)
  - site admin
- tested people with experience with blogging and other similar activities.  These are _our_ people, they just hadn't used Drupal.

Karen Stevenson:
Task 1: create a form with some simple fields so users can list upcoming workshops.
- users started with "site building"
  - spent a lot of time here, but nothing on this page gave them a clue
  - looking for "form" or "fields" - no one knew what "content type" meant
- "content" used all over the interface...
- got hung up on what a "story" is
- They only got to the right place with a call to the "help desk" - never looked under "content management"
- confused by word "content type"
- on content type page: fields tab wasn't noticed
- some thought "content types" were individual fields
- confused about page v. story
- create content and content type pages - look nearly the same - "where am I?"
- on the page to add a field, the process was pretty easy, then
  - cck widget screen is a little confusing, as was some of the terminology
- create node form - putting stuff in admin menu by accident
- teaser split - what's it for?
- when they'd submitted, suddenly the home page had their content there.  why? now navigation there is gone?
- 35 mins.

Nathaniel Catchpole:
Task 2: user management
- create user, let user add and edit workshops
- people got the permissions pretty quickly
- tended to go to access roles(?) before access control

Task 3: Taxonomy
- taxonomy help text was helpful
- people would want to find actions mentioned in text in content area, but they were in the nav area

Angie Byron:
Task 4: No one made it to task 4. (only three made it to task 3)

New users read every line of first setup page... it's a tutorial of sorts and vanishes once they make their first

Help was useless. No search.

What is a module?

People wanted a form builder.

Modules page, the "enabled dependencies" made folks think items were enabled.

People will do anything to avoid caling the help desk.  - enable all modules, for example.

Admin panel page is overwhelming. People say at the top of the page, and don't scroll down.  We need to move most important stuff above the fold.
- users expected menus to expand like fieldsets do.


Users felt stupid.

"I need a tutorial."

"I already lost the page I just created." (no menu item, not promoted to front page.) - people lost context all the time.

"Content Types" is not a good term.

"Help is useless"
- no glossary, no search, module-based help topic, rather than TASK-based.

easy stuff:
- logging in.
- permissions
- user managment
- taxonomy

usability improvements gone wrong:
- teaser splitter (cool, but what's it form)
- menu settings looks like required info
- asking for help can kill your data (ie. if you go back, you don't have your data if using IE)
- pwd security setting immediately shows red

lessons learned:
- give users early success, before destroying confidence
- you'll never look at Drupal the same...

How can you help:
- - wiki page tracking findings and tasks, discussion of findings
- issues on usability, naming convention: "UMN usability: <title>"

- real world tasks span modules, how to coordinate task usability and help text?
- change the user (better inline help, or tutorials (in site or on d.o?)), or change the interface (and vocab)?
  - probably a bit of both.
  - use the same terminology that web designers would know. Forms would mean more than "content types" etc.
  - hover text on links would help
- user group, as library staff, was likely somewhat skewed in their abilities and knowledge of vocab
- the user group was folks who knew HTML (due to the chosen user type to test)
- recognized they probably shouldn't have put a difficult task first
- eyeballs floating in Drupal soup (Kieran Lal re: users being overwhelmed by Drupal jargon)
- tabs in Garland, really don't look like "tabs"

- destined to be a high level handbook page (like /mission or /principles)

Let's repeat this.

Measure, don't guess at, the user experience.
- more usability testing.
- informal usability testing: /project/click_heatmap
- watch the usability group for more details


Boris Mann of Raincity Studios (via Bryght)

Gap fit selection and module advice

wiki page:

Business needs:
- don't just listen to requirements or features
- think about needs of the business
- what do you have in your Drupal / module toolkit to meet these needs?
- ... including identifying that Drupal is not the right tool at all

For community site, need to consider two sitdes:
- business needs: page views, ads, subscribers, etc.
- user needs: ease of use, fun, 'stickiness'

Don't like building sites for people who aren't prepared/are not equipped to run it/make it a success

Feature parking lot
- call it phase 2 or call it "not part of phase 1"
- either new or out of scope features that are not part of the original requirements

Feature | Modules              | Notes                               | Phase
forum   | advanced forum, core | schedule time to improve adv. forum | Phase 1

Internal shop list of "approved" modules.

Data description
- should be part of client intake process
- types of content
- field level data outline
- becomes the model for cck and views config
- and becomes sitemap

User stories
- refer to business needs and walk client through out of the box solutions
- create list of custom areas

Wire frames
- aka where did this chunk of content come from
- circle areas and write what data, conotent, module produces it

Issue tracking is slow to synchronize with reality

- include "end users" in process of building the site
- plan iteration time into your schedule and agree with your client what is allowed
  - unlimited tweaking of anything at the theme layer

Finding new modules
- cvs commits
- RSS feed of project nodes
- Drupal planet blog posts

If about to start working on new module, maybe send email to devel list, or do a blog post about it

Contribute business process and documentation

Fix your biz model
- please expose clients to the true cost of adding a module
- as part of requirements/features/gap fit, indicate that you need to do due diligence on a module, and charge for it
(may not be possible for all sizes of project)

Custom dev
- announce stuff that you're working on
- talk about it

Share experiences
- write up case studies
- publish lists of modules that your shop uses
- share recipies of module combinations

Project managmet tools
- gant charts
- communicates to client how their shortfalls will impact timeline of project

Better, faster, stronger
- internal install profiles
- process
- CoCKTaiL - CCK template language

- track feaures and bugs internally and externally
- expose features to the comunity
- name patches with id (for later tracking)

Charge your clients by the original work time that went into something (even if you're easily copying the config the second time)

DRUSH (use it)

Share project tools and documents

Use install profiles instead of database dumps - invest time in it upfront and it'll be better in the long run


© 2008