[Usability] Bringing GNOME Usability forward - topics for discussion in Boston and beyond
- From: Shane Martin Coughlan <shane opendawn com>
- To: Gnome Usability <usability gnome org>
- Subject: [Usability] Bringing GNOME Usability forward - topics for discussion in Boston and beyond
- Date: Fri, 9 Oct 2009 06:47:24 +0900
This message brings together several different threads on moving GNOME HIG
forward, most notably the recent posts to this mailing list by Brian Cameron
and Calum Benson. It contains the summarised outcomes of discussions with
Karl Lattimer, Calum Benson and Brian Cameron.
The overarching proposal is to update the GNOME usability project and
associated tools for the delivery of modern, simple and easily applicable
usability research and guidelines. This would assist in making FOSS desktop
technology more productive for normal users and more accessible to those with
disabilities.
The outcomes of this activity would directly support the development and
launch of GNOME 3 and would also be freely available to other projects in the
FOSS eco-system through share-alike licensing. Projects could directly adopt
or customize the tools to fit individual requirements, and benefit from the
support structures of the global GNOME community.
To realize this requires four key activities.
(Activity 1) Update and improve the GNOME Human Interface Guidelines
The GNOME Human Interface Guidelines explain how to create applications that
look right, behave properly, and fit into the GNOME user interface as a whole.
Both specific advice on making effective use of interface elements and the
philosophy and general design principles behind the GNOME interface are
covered. These guidelines are currently at version 2.2 and have not been
substantially updated for several years. While they were useful as a resource
to bring usability to the fore on the GNOME project, they are now a large
collection of style, interaction, and experience information. Topics include
spacing guidelines, icon guidelines, dialog layout, language guidelines,
shortcut key conventions, menu item conventions, input interaction and
detailed information on the placement, usage and application of each widget.
The current document covers too much ground in a hard to parse fashion, so
most software engineers don't to take time to read and apply the material. We
propose to update the guidelines by creating two documents for practical
application of usability guidelines, and to retain any additional information
in a separate reference book.
(1) The first document would be style guidelines that contain a gallery of
window layouts and their relevant applications, padding/spacing and framing,
alignments, icon guidelines and generally anything in the "GNOME Style
Guidelines" category. This document underpin UI design in GNOME applications
and would have an overview of things that UI designers can do to ensure
consistent look and feel. The format would be a pattern library as it allows a
library of common widget arrangements matched with a task and applicability. A
developer could say that 'My application needs to browse a series of folders
to populate the main view' and get information suggesting that s/he uses a
sidebar and how this is applied. In practice the document would be a semantic
data store to 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.
The pattern would potentially be a two-tier system, one being an immutable set
of core patterns/guidelines that are provided by the HIG team considers stable
and the other an unstable or pending set that's open to contributions from
GNOME users/developers. The latter may be moved into the stable set over time.
The patterns could furthermore be cross-linked to a simple coding examples
library. Anyone could contribute to fulfill the requirements of the example,
and people could translate those examples into various languages.
(2) The second document would be user experience guidelines detailing 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. This would be more of a traditional document in format, and could
probably be substantially created from the existing HIG.
These two documents will allow developers to make sure everything is simple
and effective from a user's perspective. Any remaining information would be
collected into the secondary resource book. With this structure the revised
GNOME Human Interface Guidelines could act as:
- A standard-bearing community HIG providing tools for the current
requirements and recent developments like network integration and multiple
platform applicability (desktop, mobile etc);
- A framework to unify and focus corporate investment in usability throughout
the GNOME eco-system on the primary project rather than on customized
products;
- A holistic approach to usability in the eco-system at large and be fully
adaptable by other projects under share-alike licensing.
(Activity 2) Establish a GNOME Foundation Mobile Usability Lab
The goal is to establish a lab that provides equipment for use at various
conferences, events, or hackfests when there is a need to do a usability
study. This project would allow experts to conduct a usability study and
document how it is done, so other projects can follow a template. It would act
as an enabler for the GNOME community (and the broader FOSS community) to
learn how to apply the Human Interface Guidelines. This lab would be a long-
term outcome alongside the GNOME HIG, and would travel with usability project
representatives to FOSS conferences around the world for GNOME-specific
usability, for general FOSS demonstrations and to directly assist other FOSS
projects with practical usability testing.
(Activity 3) Create a new way for GNOME to collect Usability Data
The collection and analysis of usability data needs to be improved to allow
real-world experiences to feed back into revisions of the Human Interface
Guidelines and into application development. There are three key aspects to
this: allowing GNOME users to provide more usability data, doing usability
studies in a remote fashion, and storing usability data so it is useful.
Methods to get more effective usability data might include things like
encouraging developers to test paper prototypes with users, instrumenting
development builds of software, or devising self-administered usability tests
where users run through tasks that are provided in an email or on a website,
and either record themselves doing it and/or fill in a questionnaire
afterwards. The Mobile Usability Lab would allow testing of ideas to find the
best one for the GNOME eco-system.
(Activity 4) Build a community for Ongoing Usability
The revised HIG, Mobile Usability Lab and processes to collect better
usability data are naturally maintained, advocated and enhanced by the GNOME
usability project. The launch of the new tools and processes would provide an
excellent opportunity to update that project itself to ensure that the
usability community in the project makes best use of the tools and available
human resources. A key part of this is improving the GNOME usability wiki to
make it easier for people to get involved and contribute towards the
development of usability personas, doing paper prototyping and other
activities like card sorting. This community would provide a framework for
deploying the HIG, the Mobile Usability Lab, and for processing usability data
and incoming questions.
What do you think?
Regards
Shane
--
Shane Coughlan
Business and Technology Consultant
Opendawn
shane opendawn com
Phone: +81 (0) 909 7742404 / Fax: +81 (0) 878890288
www.opendawn.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]