Update: This effort is now combined with the User Interface best practices wiki.
Original
Let's get the ball rolling on the Drupal HIG. Most publicly available available HIGs are aimed at desktop applications rather than web applications. Drupal's flexibility, however, makes it a platform in many ways, and the Drupal HIG may bear strong similarities to a desktop application HIG.
I'll update this as comments are added and ideas developed.
Purpose of Human Interface Guidelines
The purpose of a HIG is to provide developers with a set of recommendations on developing user interfaces. It aims to ease user experience by providing consistency across a system and to ease the burden of the developer when building the interface. It does not provide coding guidelines; it provides a set of recommended best practices for exposing functionality to the end user. Developers should realize that these are not hard rules and that, from time to time, it may be necessary to beak these guidelines.
Scope of Work
While I expect this document will take some effort, I don't expect it to be a tome like Apple's HIG. If it's that big, no one is going to read it. I think it's important to keep track of our rationales on recommendations, but I think it might be better to have these parallel to and not inline with the recommendations.
Stuff to Include
- Form Elements - Recommendations on when to use one form element over another.
- Text
- CSS Classes - Output text should rely on generalized CSS classes for text styles and colors. Examples would include notices, errors, and form headers. This will allow the colors and styles to be consistent with the overall theme.
- Accessibility
- Help Text - Is there an existing style guide for Drupal documentation?
- Examples
- Things to do
- Things not to do
References
- Drupal
- Existing HIGs
- Other Resources
- Designing Interfaces: Patterns for Effective Interaction Design
- Interaction-Design.org
- Interaction Design Pattern Library
- Interface Hall of Shame
- Section 508
- Usability.gov - Research-Based Web Design & Usability Guidelines
- User Focus: Usability Articles
- UX Matters :: Topics
- Yahoo! Design Pattern Library
Comments
More Ideas
My more ideas:
Modules
- The category convention of module (i.e. which category when showed in admin/build/module page)
- Where to put link in admin page (i.e. content or build or config?)
- Which kind of block should be provided (e.g. listing block for user/taxonomy-liked modules)
- Naming convention (think about when using new modules with CCK/Views and we will see some strange variable names)
- Uninstallation-able, the way to revert everything back after remove/uninstall that module
- Integration with drupal.org metadata/constraint (e.g. module 'must' provide screenshot or demo? at least it should have readme.txt?)
- Localization-able
Themes
- standard region naming convention (is 'user1' a bad region name?)
- Inheritance/Overriding system.css (or other CSS from core module)
- Integration with drupal.org too (e.g. live demo?)
- i18n (e.g. right-to-left text support)
For Help text issue, is it time to embrace Advanced Help module like Views 2?
Generally targeting classes
Generally targeting classes specifically to a style in mind is a VERY improper use. However I do agree that in some instances such as statuses that a normalized convention is nice, however more specific classes should be provided for overriding such as 'mymodule-notification notification', but I hope to never see 'red' , 'dark' etc.
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Tj Holowaychuk
Vision Media - Victoria BC Web Design
Victoria British Columbia Web Design School
Rolling it
Good initiative.
How about this:
As something that may be the "new way" (oh, oh, Clockwork Orange) after Drupalcon Szeged, I'd further suppose the following:
Personally I'll be a real pain in the ass in the future concering testing ;). Here's why: We have a lot of endless discussions, in which we express our own thoughts. But it should be more targeted towards finding out what the majority of users wants. Quick tests/reviews can settle this quickly.
Life is a process
Life is a journey, not a destination
Who it is primarily for
Both. Developers implement the UIs and even design them when no one else does. Dev-specific things, like CSS classes to use, should be differentiated as "implementation notes." Of course, the overall focus should not be on implementation.
For help text style guides,
For help text style guides, there's http://drupal.org/node/2456 and http://drupal.org/about/authoring - these are almost unmaintained (one or two updates per year), and I'd imaging many people are unaware of their existence - particulalry compared to coding standards.
Something which was mentioned at the UX sprint, and I thought was a great idea, would be having do and don't screenshots - the code style documents do this in most places, and it's much quicker to understand than trying to read it.
In my experience developers
In my experience developers don't like to read UI guidelines if they don't have to. Keeping them short and use screenshots where possible are good ideas, but the simpler you make them the more room you have for ambiguity. As has been noted, if you want to leave nothing to chance they become so complex that it takes forever to read/understand them.
A more practical approach is to provide developers with ready-to-code patterns that are accessible and already user-tested. If you have sophisticated patterns in place that are both complex enough to address most typical needs, and simple enough so they can be combined like lego blocks, then the HIG can simply focus on how to combine them and provide best practices for configurable elements such as labeling conventions and text formatting.
Issues regarding localization, accessibility, presentation of help text, or which form elements to use can be more effectively addressed if they are already taken care of by the patterns. Note that patterns can include more than just UI elements; they can address entire flows, so developers can think task-oriented rather than UI-oriented.
Drupal already does provide some patterns without calling them that: required field indication, textfield auto-completion, and error messages are examples of simple patterns (even though they're themable to the extent that you can completely undermine usability). What it doesn't provide are complex patterns that span entire flows.
In our organization we have achieved dramatic results by switching to this paradigm. Development teams can handle most of the UI work themselves with minimal consultation from the UX team, and the new designs across hundreds of very different applications are remarkably consistent. We do have a substantial amount of guidelines, but the one that is accessed the most is a decision matrix on which patterns to use for which tasks.
While our patterns are proprietary and quite specific, there are freely available patterns that have been extensively tested and are generic enough to serve as starting points, for example the Yahoo UI patterns.
A similar initiative
During the UX-sprints at Szeged we also discussed interface guidelines. We agreed write down UI best practices. All we did till now was start this wiki page: http://groups.drupal.org/node/14422
My approach would be start with the easy catches, the most common mistakes and the obvious best practices. Using Do and Don't examples images and a bit of text to explain and a target audience of developers. I did some of this already in my presentation at Drupalcon.
I think the approach you're
I think the approach you're taking is more tenable and is more likely to produce usable results sooner. It's also more compatible with community participation.
I've added the links from this post that weren't on the wiki already, and I'll update the post to point folks to the wiki effort.
Single Text Columns > Multiple Text columns on a web app
One pet peeve of mine is the use of multiple columns for displaying the same body of information on a web app when one column would suffice.
Columnized text works great on printed media as users always have a full vertical view of the text and to an extent on the front page and major landing pages (both of which need to have as many topics above the fold as possible) on websites as well.
On the internal pages of a website or the settings page of a web app, its a different story as not all users maybe able to have the full vertical view of a column due to limited heights of their monitors.
In Drupal, /admin currently uses 2 columns when all the options could be combined as one column. Two columns work well for scanning but for a new user (or one trying to find a newly added admin option) one has to scroll down with the mouse and then back up to see all the settings if screen resolution is not tall enough. Even those with larger monitors would notice that once enough modules are added, scrolling down is inevitable even with 2 columns of text.
If /admin had collapsible field sets (vertical tabs can work as well) as /admin/build/modules does, it would be a better screen as users won't have to scroll down and then back up. Two columns for the same body of text is visually stunning yet tends to be disorienting when one tries to focus on what they are reading or trying to find.
One column for the same type of text imho is preferred because while scrolling vertically can be tedious, disorientation is much less when trying to understand (not just review) whats being displayed.
What to do about D7 section in UI Guidelines
So to everybody who wants to take part in that: There is now a basic structure set up at: http://drupal.org/node/364002
What has to be discussed is what to do about the D7 section.
Problem is: it is much in the air, few things have actually been commited.
But this is also the most important section I think. What I had in mind by really documenting single UI Elements that should or could be new to D7 is to explain to Contrib and Core Developers what is behind each element and what are the advantages from a sheer UI perspective.
This - given it is done in a good way - could help a lot to push things right ahead and maybe even into core.
Waddayathink?
Life is a process
Life is a journey, not a destination
Basic Placing is corrected
A suggestion from add1sun (and a link to it :) ) made me aware that there actually is the right place in the docs for the "hopefully" new UI Elements in D7. It is in the "Comminity Initiatives" Section of the handbook. So in the orininal place cited above only Elements in D6 and already commited to Core in D7 are described.
Those Elements that "are on their way" are described here: http://drupal.org/node/367050.
I tried to give a hint to that page at the top of the issue tracker. To me, this link should have more weight. But I did not want to put the issue tracker on a subpage for now. It has been in place for some time and people would be confused not to find it anymore.
Life is a process
Life is a journey, not a destination
Structure for UI Elements description
We should discuss a best practice for the structure for UI Elements description as well what we are up to with that.
Best to meet on #drupal-usability I guess.
When are you guys normally in there?
Other I'd propose meeting on tuesday at 21.00 CET which should be 3 pm EST (Hell I have a hard time with time zones)
Life is a process
Life is a journey, not a destination
Just copy from the best :)
http://www.welie.com/patterns/index.php
http://ui-patterns.com does something similar. No need to reinvent the wheel I think.
Agreed
Looks good.
One needs to explain why and how in several steps which is lined out in the examples given by yoroy very well.
So maybe we take that common ground.
Life is a process
Life is a journey, not a destination