Re: Ideas for Usability Hackfest
Calum Benson <Calum.Benson <at> Sun.COM>
2009-10-01 16:32:22 GMT
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 <at> 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
RSS Feed