Usability Breakout Session at Drupal Core Developer Summit Notes

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

D7 UX will only be as good as contrib makes it

  1. Document and keep improving the D7 IA.
  2. Test and document core interaction patterns.
  3. Keep usability testing and execute on the results. Improve this process.
  4. Interface copy writing: continuous improvements towards consistency and brevity
  5. Document and write style guide for Seven theme.

This wiki is based on Jen Simmons' talk and subsequent meetings at Drupalcon San Francisco.
Her call was for a Drupal Module Developer UX Guide. The assumption is these are UI guidelines for administrative interfaces, rather than general site or theme implementation guidelines.

1. Document and keep improving the D7 Information Architecture

Compare the current Drupal 7 modules page IA to the proposed modules page IA. If there are differences, locate any discussions that happened regarding that. If the differences are only because noone has implemented them yet, note the differences as the future direction for development, and illustrate and document them as well.
Note: Many D7UX proposals have become a bit outdated or overruled by reality. Yoroy explains the basic high-level approach.

2. Pattern library: an inventory of core interactions

  • Go through each Core module in Drupal 7 and document each UI in general terms.
  • Take screenshots of each module UI page and crop each one down to individual controls, labeling each one by type ("Add" control, "Filter" control, "Data table" control in this example). Sort this list by module.
  • This list needs to include each page state, including what happens when empty controls become filled with data.
  • Sort the descriptions/illustrations by control type first, module second. Note the outliers:
    • Which controls are actually similar in purpose or usage but are labelled or structured differently from the rest?
    • Which controls are labelled as one thing but are actually used like a different control?
  • Document the dominant uses as existing patterns, including:
    • "What" (a description of the pattern including at least one illustration).
    • "When" (when to use the pattern, what problems it solves).
    • "Why" (the reasons it's best to use this over other possible solutions).
    • "How" (Drupal code that generates the pattern for one or more scenarios).

    Additional illustrations showing the pattern in consistent use are also a good idea, as well as links to the Designing Interfaces or YDN Patterns references.

This should result in a pattern library of the existing practices within Drupal 7 Core administration interfaces.

These are not necessarily the best patterns, but implementing along these guidelines would result in a consistent experience. It would be reasonable to note this document as a guideline and discuss enforcement, coder module support, etc., at this point. What's working? What's not working? Talked about the start of this in Paris. Are we still stalled? Bojhan finds the UI standards scope to be for 4 years now.

On tips, checklists, guidelines, best practices, and canonical stone tablets

  • Rules about buttons
  • Rules about order of common fields in fieldsets
  • Preferred wording for labels or certain elements
  • Guidelines for interface behaviors
  • Pattern library for layouts

"It depends" is the one only rule written in stone. Everything else is always almost up for discussion as the context wherein stuff is applied is so important.

Standards for alignment of form elements — Luke Wroblewski wrote the book on Web Form Design.
Need a better system on Drupal.org, need a canonical document, need a standard specification, be able to flag and have version history "spec guideline Drupal 7 stable"
Can this be a dictatorial process? Difficult to get that support. Don't try to change big things out of the gate. Drupal 7 UX stuff is good (we really don't know this yet!). Standardize it. Having Jen write down what her points were would be really good. "Put save button on the left, standard."
Is this an authoritative document? Is it a requirement for getting something into core? Or is just recommended to design your modules this way, but no consequence? Then authority is more about persuasion and not about decisions. Elements that will be some of both. When you have standards such as 508 and W3C. Authority matters on those guidelines, you can be dictatorial on those, but other design elements...authority trickles down from there.

3. Usability engineering

The usability testing at Baltimore is what brought this issue on people's radar.
Another round of formal testing is needed to actually be able to validate the design decisions made. It's expensive and needs a lot of resources for analysis and then to get it into actionable issues in the queue.

It’s always best to have usability testing done in person. But you can get useful results with testing that is much easier to put on than the typical formal usability test. The simplest method is to call someone up and have them do the task on their computer, thinking aloud, while you follow along on your own. Yes, you lose a lot — the facial expressions, certainty about where they are looking when they grow quiet — but you gain a lot, too. It's easier to set up, for one thing. For another, they are working at their own computer and in a familiar setting, not with a strange keyboard, mouse, and monitor in a testing lab. More testing can be done without having to have access to a formal testing lab. [@Kevin, where have I seen that paragraph before? ;-) –Cliff]

Where and how?

For the button example, that is a place where we have an opportunity to create an API, theme function or whatever, make it easier for developers to make usable pages. That is what the API does by default.
Automated testing of user interface layout, screenshot tools, somehow tell programmatically?
Always be consistent, even if bad, but for administrative interface always be in the same place.
Is this all the comments on the page, or in issue queue, or where?
Documentation is moving to its own website, and they are building new tools that are going to handle a lot of these issues.
API stuff has tabs across the tub, and not much else in terms of clutter. Drumm is going to change those, doesn't want to have to deal with the menu system anymore.
docs.drupal.org will be on its own server. There is an issue queue for this.
If there is problem with interface of the site, that goes under api module queue, theme queue, webmasters queue, or drupal.org queue.
Article on good choices for solving this problem. A pattern library. Have to simplify the language; otherwise, the information means nothing to a lot of people.
Tags, needs security review, needs etc., can look back at the history and see if it was there before and was removed, and then you know if it was done.
Definitely do more UI reviews in the issue queue. The more we do this the more we will figure out what the process will be. +1
Just doing design reviews over and over again teaches you really fast what works and what doesn't. Just do them for UI design.
Complex user interfaces through the UI would be worth investigating and reviewing individually, but they are built in and available UI components within Drupal 7.

References

Drupal

Elsewhere

Examples of UX style guidelines

Examples of pattern libraries

Comments

Excellent, thank you. We

yoroy's picture

Excellent, thank you.

We kicked off some things in Paris indeed: http://www.slideshare.net/yoroy/building-block-for-your-modules-ui
There's a lot to be won with a consisten use of terminology and shorter, much shorter form descriptions and help texts.
For the guidelines, we want to document and suggest best usages for the ui interaction patterns like tables, vertical tabs (no, you don't use them everywhere, they have very specific use cases) contextual links etc. etc.

We did a lot of good things with D7 core, the next challenge is to work with contrib authors to align their interfaces with what's happening in core.

Reviews and usability tests are good for that. Canonical docs is a nice idea, but problem with good UI is that it depends on the specific context of each use case that. The one basic rule for good ui is "it depends" :)
Still there's enough little basic things (like button placement) that we can document and set in stone. Checklists.

Doing real-time editing of a doc at DrupalCon SF

vmiliano's picture

Can't seem to post anything or edit the wiki doc, spam filter keeps blocking me, so doing real-time editing of a doc here: http://typewith.me/t8M5BxmNWZ

Boo to the spam filter! Well

coderintherye's picture

Boo to the spam filter! Well let me know, I can always edit it this page to bring the changes.

Drupal evangelist.
www.CoderintheRye.com

Okay

vmiliano's picture

I'm done with the framework to-do list doc at the above URL for the moment. If the plan is okay, can we post it somewhere and make a place for the work to be done?

I added your notes to the

coderintherye's picture

I added your notes to the wiki page, but we need to edit all the notes into something manageable/readable.

Drupal evangelist.
www.CoderintheRye.com

In regards to the pattern

Bojhan's picture

In regards to the pattern library, I would think the most interesting information is rather finding out what kind of information module maintainers wasn't and properly inventorize those needs. So finding out which patterns we need to cover, rather then assuming we should cover x,y,z. So this means discussions, interviews and lists of conversations with module maintainers.

As a module developer myself,

vmiliano's picture

As a module developer myself, the only references I know about are linked to from that doc, and I didn't even know they existed before Saturday. I don't think module developers are missing specific kinds of information; it feels more like they're missing all the information. I certainly was. :/

My assumption with documenting Core first is just that a consistent interface is better than an inconsistent one. By documenting Core, you have a reference of "the official way" that new 7 module developers and those doing ports can use as a guide.

I'm not sure most module developers think in terms of design patterns, or even know what that means: people asked what it meant at the breakout. Providing an example sourced from Core gives us a base to start explaining and getting people to think and talk in terms of "what is the problem I am trying to solve" instead of "how can I most easily (for me, the developer) collect this data."

It may not be interesting work, but in the past when I've written style guides and pattern libraries from existing work, this has been the most successful (which is often just most incontrovertible) way.

Is there something wrong with the approach, or just with the amount of effort it will require? I feel like it's necessary effort given how not-design-conscious parts of the community seem to be.

There's not that much

yoroy's picture

There's not that much difference in what you two are saying. We have a nice new set of patterns in core. We want to document and provide guidelines. To provide sensible guidelines, we need to know the contrib developer needs. I don't think it would be wrong to keep on prototyping the format for this.

I think all Bojhan is saying is that we damn well provide patterns and guidelines that make sense and are somewhat tested out in the real contrib world so to say. The risk is that releasing early with shaky advice on unproven interaction patterns can be damaging to d7 ux instead of improving it. Especially since the non-experts are so eager to start applying all this unwisdom.

Let's definately keep the ball rolling though. Oh yeah, that wiki dump above. Lemme see what I can do.

OMG, notes dump looking so

coderintherye's picture

OMG, notes dump looking so much better now!

Thanks :)

Drupal evangelist.
www.CoderintheRye.com

One reason I hope I can

coderintherye's picture

One reason I hope I can really contribute here is that I maintain a module, and I am also evangelizing on accessibility and usability. (Though, my own module needs work in that area as well still). So, I understand the point, you don't want to just throw some hard to understand guidelines at maintainers, you want them to have simple, concise information which will allow them to easily implement changes. (e.g., A coder module for accessibility and usability would be amazing, if such a thing could be done).

Drupal evangelist.
www.CoderintheRye.com

thanks !!

drupalthemeplayer's picture

VERY good work guys ! Thanks ! This is it !

Nice!

mgifford's picture

This is the most comprehensive guide on UX I could find. Gotta get that consolidated and moved over into the docs.

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week