[Usability] Moving forward: (Activity 1) Update and improve the GNOME Human Interface Guidelines

[Shane Martin Coughlan <shane opendawn com>]

Hi Calum, Karl

We recently talked about how the HIG can be updated by moving towards a 
pattern library style (summary below for people new to the thread).  It 
appears that feedback about proposal has been positive.  

That's cool.  In my opinion the pattern library update sounds awesome and I 
want to see it happen.  Gnome has a great opportunity to provide some landmark 
FOSS guidelines for modern computing.

I'd like to discuss how all this stuff can be made a reality with our current 
resources.  As I understand it these are as follows:
 - At least two professional usability chaps (that's you)
 - A big existing HIG
 - A bunch of volunteers who care on this list
 - A website/wiki
 - A deadline of March 2010 to meet the Gnome 3 release

Putting the bits together, and to assist with discussions in Boston:
 - Given the above resources how realistic is a March 2010 deployment?
 - How many hours (ballpark) can you commit to this adventure?
 - What type of stuff should volunteers do (a) right now and (b) in one to two 
months to support the development of the new HIG?
 - Are there are dos and don'ts or gotchas that tend to hobble HIG development 
that we need to avoid?

Everyone else, any more thoughts for specific additions to the proposals below, 
for methods to apply in making them a reality and what resources (time, love, 
affection) you can bring to the table?

=== Background: stuff people talked about doing to make the HIG better ===

The reference document in the past was "The GNOME HIG" and it started out 
well.  The wiki version was very useful.

However, the HIG as it stands is a massive confabulation of style, 
interaction, and experience guidelines that's been brought together in so much 
detail nobody cares to read it any more. It contains:
 * Spacing guidelines
 * Icon guidelines
 * Dialog layout
 * Language guidelines
 * Shortcut key conventions 
 * Menu item conventions 
 * Input interaction
 * Detailed information on the placement, 
   usage and application of each widget
 * and much much more...
It's become a book, in fact it's even called the HIG-book,

We need to think about short documents which engineers actually use; 
guidelines which are actual guidelines and a book which is just a book, not a 
book of guidelines. 

The way forward may be to create two documents.

(1) Style guidelines that contain a gallery of window layouts and their 
relevant applications, padding/spacing and framing, alignments, icon 
guidelines and generally anything which is "GNOME Style Guidelines" worthy. 
This document becomes the main Bible of UI design for GNOME applications. It 
has an overview of simple things that UI designers can do to ensure a 
consistent look and feel with GNOME. 

A pattern library would be ideal, as I understand it what you'd be
expecting here is a library of common widget arrangements matched with a
task and applicability, for instance;
'My application needs to browse a series of folders to populate the main
view' - Use a sidebar, this is how, etc, etc.
The problem with these kinds of libraries is browsability, a semantic
data store could work in the following way;

    sidebar app         tabbed app
    /     \             /    /\
   /       \           /    /  \
nautilus  multiple docs    /  web browser
                     \    /
                      \  /
                       \/
                       gedit

This would allow a developer to think "x app is similar to mine in
this respect", and then find all of the patterns related to that app.

Here are examples of the pattern method:
http://www.welie.com/patterns/  
http://developer.yahoo.com/ypatterns
http://www.uie.com/articles/elements_of_a_design_pattern/

Ultimately what might suit GNOME best would be a two-tier system -- an  
immutable set of core patterns/guidelines that are provided by the HIG  
team up front and considered stable, and an unstable or pending set  
that's open to contributions from GNOME users/developers (but reviewed  
by usability folks of course), which might be tweaked, replaced, or  
moved into the stable set over time.

An ancillary section could be code snippets.  It could be cross-linked rather 
than incorporated it into the pattern library itself. A simple coding
examples library would be a benefit in itself, in there we can have
anyone contribute an example to fulfil the requirements of the example,
and people could translate those examples into various languages.

(2) User experience guidelines would be the second primary document, detailing
information on the kind of language that should be used for error messages, 
usage of widgets/controls, input interaction, default shortcuts and anything 
else which becomes UX relevant. 

Essentially these two documents can become a simple set dos and don'ts
for developers to make sure they've got things right.  The HIG in its entirety 
should probably be renamed to "The GNOME Human Interaction Specification" - or 
something equally official in order to signify it's detail.

The shorter more accessible documents can be generated by reducing content
from the existing HIG. There's a massive amount of redundant or obvious
information in the HIG at present which can safely be removed during the
process of reducing to these shorter simpler documents without opening
up any gaping holes in the consistency of the desktop experience. 

When it comes to practical application it is worth noting that GNOME 
previously had IRC-based UI reviews prior to each stable release, where we got 
some usability, a11y and docs people to look everything over post-UI freeze.  
In theory, anything that didn't pass muster could be dropped from the release, 
although that never happened in practice.
http://live.gnome.org/UsabilityProject/Archives?action=AttachFile&do=view&target=howto_write_ui_review.html
There were problems with that approach, though (never managing nearly  
enough coverage, and happening too late in the cycle to do anything  
other than papering over cracks anyway), and we haven't done one of  
those since 2.14.  So right now, in reality, there are no official  
usability checks before (or indeed after) a module is proposed.

A new review process could be created to deal with the known faults of the 
existing systems once the two new usability documents are created.

The strictness of application has to be defined, but it is worth considering a 
situation whereby if something does not fit with the guidelines then it
isn't accepted for inclusion in GNOME, but can still be hosted on GNOMEs
servers. I think it's very important for us to show that we want to
tackle the consistency and usability in a formal manner from now on. 

=== End of summary ====
-- 
Shane Coughlan
Business and Technology Consultant
Opendawn
shane opendawn com
Phone: +81 (0) 909 7742404 / Fax: +81 (0) 878890288
www.opendawn.com