A usability / UI project is only as useful if it results
in change in the interface. This requires people actually implementing the
ideas, concepts, prototypes, etc developed . Given the apparent difficulty
(based on past UI initiatives) of attracting hacker support, a lot of our
approach has been tuned to encourage hacker involvement. Surprisingly, as
we began to play with various ideas for involving hackers, we found that
they were more appealing to us too. We believe the fundamental tenant for
the success of the project needs to creation rather than conformance.
Conformance means taking principles of usability and attempting to wrangle
hackers into following them. The approach this usually entails people with
UI interest examining existing applications and either providing revisionary
suggestions, or modifying their interfaces to be somewhat easier to use.
It is difficult because hackers largely view suggestions without code behind
them as clueless crap, or worse if the body claims some official position
as the gestapo. A common perception seems to be that usability is about "dumbing
interfaces down", and in a sense makes advanced users and hackers feel like
that a usability project is attempting to steal the desktop from them in
terms of their own enjoyment of it.
The creative process differs in that it attempts to achive a more usable
desktop by focusing on enticing hackers by demonstrating cool interactions
(and usability) that makes a particular tool or project substantially better.
In a sense what we are designing is new software
to be written rather
than old software that needs to be revised. In my own personal experience
it is far more interesting to develop a new tool than to fix on old one (and
of course, this is largely true for the usability engineers involved too,
we get to start with a blank slate). This fits very well with GNOME's current
phase of evolution. We are about to roll out a new, more complete development
platform with GNOME2 that should significantly enhance the project's ability
and ease in writing new applications.
In many ways, our process seems to be paralleling the historical development
of Microsoft Windows which started with extremely little attention to usability
issues, did a minor rewrite of the desktop along with a first-reasonable-cut
of a development platform producing Windows 3.0. Windows 3.1 was very similar
in terms of interface but in terms of the development platform eventually saw the introduction of OLE and the
new Win32 API (though it never achieved widespread use under Win 3.1, much
as Bonobo has yet to achieve widespread use on the GNOME1 platform). Using
their new API and a better understanding of usability, and experience in the
mechanics of developing a desktop environment, Microsoft released Windows 95,
a near complete interface rewrite based on their new development technologies.
Similar processes can be seen to be at work with the Macintosh operating
system. What is the point of this? It seems likely that much of GNOME is
going to be rewritten in the next year or so. Part of this has already ocurred,
that being Nautilus, and part of it is ocurring as we speak (the Control
Center). It seems likely that the first major segment of the desktop we can
influence from the ground up will be gnome-core (a very
part of the user experience).
Rather than playing catchup and trying to fix the minutia we observe as
wrong in other applications we should be leading the effort in prototyping
the look-n-feel of the desktop, its access to information, conventions,
messages, and other very fundamental aspects of its operation. Within the
technical constraints of the development platform we may have the opportunity
to essentially start with a blank slate. Do we want a MacOS style menubar?
Should a filesystem even be used for storing documents or should documents
be persistent like the Apple Newton? Should we use an Application->Document
paradigm, or should we attempt to focus the user experience on Documents
with Applications being incidental details? Should their be panel, or is
there a better central access mechanism? All these questions are potentially
open for review (and of course many many more). This is about making the
process of designing the GNOME interface explicit rather than the haphazardly
dispartate growth it has undergone to this point. Much the same as we recently
decided to review how the different aspects and technologies of the GNOME
development fit together from a larger perspective, we need to do the same
for the interface.
Realistically, we do not have time for all of this within the GNOME2 development
frame, but on the other hand if we do not start preparing for post-GNOME2
now we won't have time to drive some of these changes into GNOME2.2 or GNOME3.
That said, we cannot entirely shirk our responsibility to deal with pressing
interface problems (particularly those that stop user's progress at a very
early stage such as logging in or launching basic programs), or those that
are very simple to fix implementation wise.
We envision three major areas of focus, perhaps reflected in having three
seperate working groups.
- Writing a style guide
- Fixing the most critical and broken issues facing the GNOME2 desktop
- Working on engineering the next generation GNOME interface
These tasks are all integrally related in various ways, so we need to
maintain tight communication between them, but a large body of the work
can be seen as seperate and very different. For example, the ways we fix
the most critical issues will be a part of the formative process of the
style guide (as it will give us a realistic flavour of ways hackers might
obfuscate their visual interfaces, or common interaction problems across
the desktop). Similarly the style guide will need to be in-line with our
next generation designs (realistically a style guide will probably not be
ready for GNOME2, so it should probably focus more on integrating with the
vision for the next generation interface). Also it might be good to publish
a shortened form of the style guide within the GNOME2 timeframe that addresses
the most pressing issues so the mistakes are not recreated.
Who are We?
The Style Guide
a meeting in ten short acts
Given the short timeframe until the planned GNOME2 release, I am not sure
it is possible to achieve a full style guide for such.
Point of discussion 1: Do
we want to produce something for the GNOME2 release? Could we finish
a complete "basic" style-guide for GNOME2? Would this tie us to ill-chosen
conventions we don't want to maintain?
Organizationally, we also need to decide who is going to work on the style
guide team. Similar to the organization of most development projects within
GNOME a small number of people should probably form the core of the team
and will accept patches changes, and hopefully write a great body of the content
themselves. We also need a style guide module maintainer.
Point of discussion 2: How
many people should be working at the core of the style guide? Who should kick
off the style guide?
Additionally there are a few started GNOME style guides we could choose
to base off of, and a few completed style guides we could copy wholesale and
modify. These include mpt's GNOME style guide, czr's GNOME style guide, the
KDE style guide, the MacOS/X style-guide, the Windows style-guide, and a
few others I can't remember off the top of my head.
Point of discussion 3: Do we
want to start from a completed style guide and make modifications? Start
from one of the existing partial GNOME style guides? Start from scratch and
draw source material on a case by case basis from other guides?
Fixing BrrR0k3nesS5 for GNOME2
We should probably focus on "major areas of the GNOME desktop" or applications
we expect to have a very high percentage of users interacting with. These
include the panel (particularly the panel menus and perhaps the applet situation),
tweaking various aspects of Nautilus, the control center, and high profile
applications like AbiWord, Gnumeric, Galeon (where they are significantly
broken, though I can't think of any ways off the top of my head that are
must-fix), gdm, the window manager, and task switching.
Point of discussion 4: Lets
draft up a must-fix list and start prioritizing it. Bugzilla might be ideal
for this, or we could choose our own organizational system.
Another objective we may want to adhere to for GNOME2 is to enhance usability
in ways that improves the quality of experience for advanced users and hackers.
Why? Many hackers are opposed to usability because they see it as "dumbing
down the interface", something obviously treated with scorn. This fails
to recognize that good usability will have a positive impact on everyone.
Particularly given that most of the existing GNOME audience are fairly computer
savvy, it seems important to concentrate on issues that affect this audience.
We are not going to make GNOME your mother's desktop without some major
rewriting, so lets work on interaction problems that make the experience
more comfortable for our existing audience, and save the former for our
vision for the future of GNOME. One suggestion, for example, would be to
organize the menus in a more easy-to-use way. Even with competence and experience
on the GNOME desktop it is sometimes difficult to find things inside the
GNOME main menu structure.
Point of discussion 5: What
are some big usability / interaction bugs that hackers may not have even
noticed that we could potentially eliminate? How can we best serve GNOME's
Designing for the Future
We need to start figuring out how we are going to connect with hackers
and excite them about working with us. This is not a single-handed sort of
thing, but a collaborative process between designers, artists, and implementors.
Particularly in this area its important to have involvement from people who
are highly skilled and respected in areas besides usability, as this will
shape their aspect of the desktop as well in very significant ways.
Point of discussion 6: How can
we excite hackers about working with us? What projects would they be most
interested in working on?
In addition to looking at parts and aspects of the GNOME desktop that are
likely to be rewritten, we should consider missing pieces that we can design
right from the start. One example of this might be a system for managing
panel applets that is more intuitive and explorable than the existing method.
I suspect that people will be much more interested in writing a new piece
of software than fixing on old one, so we can present this as a project unto
itself. It is important for a usability project to consider the environment
as a whole, as this will allow us to see cross-application interaction problems
as well as notice missing pieces.
Point of discussion 7: What are
some missing pieces of the desktop that we could design?
Additionally, we should figure out who/what needs to be involved in the process
of designing for the future (for example, artists, the foundation board,
Point of discussion 8: Who do
we want to engage to move forward on this in a way that is supported by the
greatest number of people?
Point of discussion 9: When
should we meet next?
Its important that we develop a smooth and sustainable working process (though
this may differ between the three major subtasks, as they involve very different
processes). We also need to consider ways to best accomodate a broad range
of talents, interests, and time commitment. Some of the considerations this
brings up is how long we want decision turnaround to be (this alters how
often we expect a productive contributor to have to check e-mail, for example),
or how/whether we use technologies like CVS for our content.
Point of discussion 10: How do
we decompose organizationally? How do we work, how do we collaborate?