Re: A call to action / Guidelines

["Christopher D. Beland" <beland MIT EDU>]

> Where can I find the outline of the Apple Human Interface so that we
> can start putting GNOME stuff in it?

The Macintosh Human Interface Guidelines are accessible from:

http://devworld.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html

Adopting these guidelines for Gnome looks like it would be a
monumental task.  It's also not the most straightforward job in the
world.  In creating a distinct "look and feel" for Gnome, a whole new
host of small usability issues is bound to be created.  Also, I think
Apple has not always made all of the right decisions (and many times
there are multiple "right" decisions) so we must also rely on the
expertise and experience of Gnome developers, users, testers, and
designers to know when to deviate from the historical path.  But, as
people have said, it's almost certainly worthwhile - as long as it
makes an impact on the actual product.

The key question is how will the Guidelines (whether they are spawned
from this list, Eazel, or elsewhere) actually affect the
implementation process.  For small things, like placement of objects
in dialog boxes, the Guidelines can make UI improvement as easy as
filing a bug report.  ('Section 2, paragraph 5 specifies the button be
in the lower right corner, and Section 3, paragraph 2 states the
standard label is "close" not "cancel".')

Presumably, if developers feel the consistent look and feel the
Guidelines mandate is reasonable, they'll make corrections.  Even
better, if they feel consistency and user-friendliness is important,
they'll make such corrections a less-than-negligible priority.  I
think developer attitudes are mostly a function of how well the rules
are written, how they are presented to the community, and how
responsive to developer needs and input the process will be.

The Guidelines leave many higher-level problems unsolved.  For
instance, even if the session management system has every button,
switch, and light in proper order, users may still find it confusing
to use on a conceptual level.  It may need to reorganize its interface
in a new paradigm, or even add or lose some functionality.  How can
developers get this sort of feedback, and what role might this list
play?  I see the following possibilities:

1. The developer(s) is part of a large organization that includes UI
specialists.  In this case, gnome-gui-list is probably best advised to
leave development in the hands of the experts, as there are too many
other project getting zero UI attention to waste resources
second-guessing other teams.  

2. We see a need for UI attention in a particular program.  We
approach the maintainer and ask them if they'd consider implementing
some UI improvements if we came up with some suggestions.  If the
response is positive, we have a conversation about the program over
the list and/or IRC, and someone volunteers to summarize the
discussion in the form of a report to the maintainer.  (Developers
would be encouraged to participate in the discussion, of course.)

3. If the maintainer in (2) says they have no time to implement UI
improvements, but wouldn't otherwise be averse to them, then we still
might find a volunteer who would be willing to consider implementing
our suggestions.

4. The situation is complicated, our expertise is insufficient, and/or
the developers disagree with our off-the-top-of-our-heads suggestions.
Someone needs to start collecting real-world data, perhaps by
organizing UI feedback from users at large, or by getting the program
on the agenda of UI experts and/or formal usability testing.

5. A developer asks for our assistance.  Yay!  See 2.


Perhaps the Guidelines can be written in a collaborative fashion.  We
seem to be quite willing to spend endless hours debating the "shoulds"
of various things; why not harness that energy?  For each section of
the Guidelines, someone could volunteer to draft something simple,
short, and stupid.  8)  Then we could have a discussion, which the
volunteer would then summarize in the form of a revised statement.  We
could iterate through the various sections.  In the end, we would have
a set of Guidelines we could present for comment from developers, the
public, and UI experts.

I think the key elements in this process would be a.) getting enough
people to volunteer small amounts of time for small portions b.)
collaborating with enough people (UI people at Eazel and Helix Code,
developers, project leaders, etc) to gain momentum and acceptance c.)
publicity and d.) follow-through on actually writing the reports and
evangelizing their contents.  

But I have the sense that mysterious goings-on inside private
companies or higher up in the Gnome leadership may be pre-empting the
need for such an initiative.  (Personally, I have no idea how Gnome
really works in a social sense, and I have not had enough sleep lately
to trust myself to propose much of anything with complete sanity.)  It
would be useful to touch base with the people in those circles, who
are certainly all strangers to me.


In summary, we need to strength both the (idea -> document) and the
(document -> code) processes in order to make this list an effective
tool for UI improvement.  We also need to become more aware of other
UI initiatives and how they and we fit into the project as a whole.
Perhaps turnover on the list would be less if it had both better
productivity and recognition.


If only I were paid by the word,

Beland

===============================================================
Christopher Beland - http://web.mit.edu/beland/www/contact.html
MIT STS/Course 6 (EECS)   -   MIT Athena User Interface Project              
                   http://www.votenader.org                   
===============================================================