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

[Shane Martin Coughlan]

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@...
Phone: [phone] / Fax: [phone]
www.opendawn.com
_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability

[Karl Lattimer-4]

On Fri, 2009-10-09 at 10:42 +0900, Shane Martin Coughlan wrote:
> Hi Calum, Karl

Hi Shane,

> 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?

As I'm not making it to Boston, I'd like some things brought up;

Firstly, my initial focus will be to digest the HIG, reducing it down,
to something which covers most topics broadly and in few pages. I can do
this on live.gnome.org. I think this can be achieved in about a days
worth of work. Which I can provide at some point in the near future.

What would be helpful to me is if at boston people could spend the time
in a group identifying areas of over specification, e.g. duplication,
unnecessary detail etc... and also identifying key areas which they feel
must remain even in the HIG-lite.

Regarding the implementation of the pattern library, I haven't paid
attention enough and am not sure what's powering library.gnome.org, it
appears that it's maybe a drupal book? If so, then it's possible to
build a set of semantic relationships between book pages somehow (Sam
Taylor was showing me something like this on wine-doors.org a while
back). This would allow us to implement the graph of links discussed in
the original post.

Does anyone want to do the investigation into this side of
implementation?

The next thing I wanted to bring up is a killer feature, it would be
absolutely awesome, is if we could make notes along side the pages of
the book, and have those notes attributed to author, time/date and point
to a specific section. Sharing notes in GNOME documentation would save a
lot of discussion time :)

This might be a little off-topic, but I wanted to mention it.

> 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.

Obviously including the annotation feature in a code example library
would also be cool.

BR,
 K


_______________________________________________
Usability mailing list
Usability@...
http://mail.gnome.org/mailman/listinfo/usability