[Usability] Bringing GNOME Usability forward - topics for discussion in Boston and beyond



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]