D7 UX will only be as good as contrib makes it
- Document and keep improving the D7 IA.
- Test and document core interaction patterns.
- Keep usability testing and execute on the results. Improve this process.
- Interface copy writing: continuous improvements towards consistency and brevity
- 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
- Drupal UI guidelines
- Drupal 7 configuration page information architecture
- Drupal 7 user interface elements
- Drupal 6 user interface elements
- User interface best practices
- Drupal markup (HTML/CSS) style guide
- Drupal JavaScript style guide
- Drupal CSS style guide
- Examples module, showing live code as an example for module implementers
- Drupal 7 UX discussion group (unused, post in g.d.o/usability instead)
- Developing for Drupal
Elsewhere
Examples of UX style guidelines
- A partial doc I wrote for a client
- The drupal.org redesign style guide, of which relevant sections are:
Examples of pattern libraries
- Jenifer Tidwell's Designing Interfaces, published by O'Reilly
- Yahoo's design pattern library
- Individual, similar references: