Re: [Usability] Ideas for Usability Hackfest

[Calum Benson <Calum Benson Sun COM>]

On 28 Sep 2009, at 23:36, Brian Cameron wrote:

> - Next revision of the GNOME HIG
>
>  The HIG is still in draft form, and does not discuss newer
>  technologies such as clutter at all.  The HIG needs some real
>  attention to ensure it continues to be helpful with GNOME 3.0.

A few of us got chatting off-list this week about possible direction  
here, attached is the summary so far (thanks to Shane Coughlan)...  
thoughts welcome.

=== Stuff people talked about ===

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 ... dum de dum ... 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 some 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 ====

Cheeri,
Calum.

--
CALUM BENSON, Interaction Designer     Sun Microsystems Ireland
mailto:calum benson sun com            OpenSolaris Desktop Team
http://blogs.sun.com/calum             +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems