Linux Today: Linux News On Internet Time.

Miguel de Icaza: Reorganizing the [Gnome] UI team

Oct 24, 2000, 22:40 (5 Talkback[s])
(Other stories by Miguel De Icaza)
Date: 24 Oct 2000 14:46:03 -0400
From: Miguel de Icaza miguel@helixcode.com
To: gnome-announce-list@gnome.org, gnome-ui-list@gnome.org
Subject: Reorganizing the UI team.

Hello guys,

Executive Summary:

        * A call for volunteers to extend the life of the GNOME User
          Interface team.

        * A call for people who want to coordinate the individual
          parts of the team.

        * If you are interested in a managing role in the project,
          please read to the end of this message for further
          instructions ;-).

* The User and Developer Gap.

   Last year I created a team that was managed by Jim Cape: the GNOME
   UI team.  The purpose of this team was to close the gap between
   developers, users and human interface experts and visionaires.

   The problem is that developers many times think in terms of how
   their application is structured, and their range of needs and
   things they consider important for an application might not be the
   same ones that a user needs.

   The problem of human interfaces is that there are many opinions on
   how what an user interface should look like, or what the behaviour
   should be, and which things are ergonomic and which ones are not.
   So developers find themselves having a hard time following through
   the discussions on the mailing lists.

* What we need from the UI team.

   There are various tasks required in GNOME that can be classified as
   "human interface" work:

        * A comprehensive document with guidelines for user
          interfaces.  Basically, a free document (FDLed hopefully)
          that could be used as a handbook of user interfaces.

        * GNOME look document.

        * A quick reference guide/checkpoint list for a good user
          interface in GNOME.

        * Collecting human interface ideas, presenting them to

        * Developers willing to implement those ideas.

   Details follow.

* Collecting user interfaces ideas

   So a way of collecting the suggested improvements and catalogue
   them with various criteria is required:

        * By complexity: an estimate of how hard it would be to

        * By impact: how much better the  user experience would be.

        * By radicalism: is this a major shift in the user interface,
          is it not?

   All of these need to be kept, so developers and contributors and
   casual contributors can go to a single spot and implement.

   It is best if ideas for changes in the user interface layout
   contain a screenshot or a mockup of the suggestion.

   Of course, code would be nicer, but we realize that the divide
   between developers and user interface contributions might not allow
   this to happen.

   This could contain examples of what we consider to be good ideas -
   maybe even things like "this problem was hard, but we thought this
   solution was pretty elegant" -type real world scenarions. Ideally
   this will expand as things are developing, so all the ideas would
   get stored here as a resource for future needs.

   Mockups could be screenshots, or .glade files.

* The Old UI Team

   Jim Cape and the various contributors to the GNOME UI team produced
   loads of mockups that would enhance GNOME, together with a
   rationale of how it would actually operate.  Not only this, but
   they provided animated versions that allowed us to see what was

   Their input was integrated at various stages in various places: the
   GNOME Panel (Jacob and George), the GNOME Control Center (Jonathan,
   Bradford, Justin), and various capplets (we even hired people to
   implement the suggestions made by the UI team).

   Some of the input was implemented in modules that have never been
   released to the public (like the file selector that was part of
   Ettore's work on the GNOME VFS).

   The original announcement for this happend last year:


* The Quick Checlist

   We also need to put together a small and precise checklist that
   could help people develop good user interfaces, the check list
   should be used by applications developers as a resource they can go
   to make sure their application is as good as it can be.

   The checklist can be divided in many areas:

        * User Interface elements.
                * Standard naming/contents of menus.
                * Standard mouse bindings for actions.
                * Standard help elements.
                * Try to use the following stock icons, etc, etc.
                * Try to use these keybindings, etc, etc.

                Some of these are easy to do, as gnome-libs helps
                addressing them.

        * Feedback features.
                * How kind of feedback your app should have.
                * Long operations.

        * Accesability features.
                * To be defined, maybe Sun can help here.

        * Internationalization support.
                * How to internationalize an app.
                * Pitfalls on internationalized apps.

   The quick check list document should not be a huge document, but it
   could contain links to other sites and the larger user interface
   document that Arlo is preparing.

   This should be faily "rule of thumb things" that is not too complex
   or lengthy. Something that every developer should skim through to
   get an idea how things should be done. If it is too complex, it will
   just left collecting the dust.

* Ergonomics

   GNOME has grown a lot since it began.  In the beginning, there was
   xterm and gcc.  Now we have a pretty complete desktop system that

   But a working system is not the ultimate goal here, the ultimate
   goal is to make GNOME so ergonomically perfect that even when the
   fact that it is free software is a great compelling argument,
   people will not resist the need to install it, and run it and have
   everyone just use it all day.

* User Testing

   Arlo would like to see user testing be a full part of the
   production of this user interface effort.

   This is a bit more complex, as it requires the help of programmers
   to implement the features and packages needs to be made available
   to end users for testing a specific usability improvements.  And
   repeat this process until the perfect interface is achieved.

* Coordinating the effort

   I have created a mailing list called gnome-ui-hackers@gnome.org for
   people who are interested in organinzing and managing the process
   of improving the user interface, and those of you who might help
   collecting ideas, organizing them, and creating mockups and those
   coders whose biggest interest is to implement the various usability
   ideas that are required in GNOME.

   Please note: gnome-ui-hackers is not for discussing the user
   interfaces ideas, nor discussing what is good, what is bad: it will
   be used by the volunteers that will be doing the work described
   above.  The standard discussion about user interfaces should
   continue in gnome-ui list.

   So we need various volunteers that will take over specific areas,
   those will become the "maintainers" for that portion of the
   project.  We will provide them with access to the GNOME CVS
   repository so that they can maintain the web pages for the project.

                * Web helper for the UI team: will help coordinate
                  and/or author the web pages for presenting user
                  ideas to developers.

                * Someone to write the User Interface Guidelines (Arlo
                  has voluntereed to lead this effort or act as its
                  editor, hopefully Arlo will provide accurrate data).

                  We will also include a set of stock icons that
                  people could assume that will be available on their

                * Someone to write the User Interface Quick Check

   Arlo and Tuomas have expressed their interest in takin an active
   role in this project.

* Volunteers

   Besides the organizational volunteers, we will need programmers
   interested in improving the user experience: both programmers that
   would like to implement the suggestions, as well as programmers
   that would like to be part of the usability lab effort: to iterate
   over the code back and forth.

I will be peeking at the mailing list, but I do not have any time to
offer in any of the above areas, but I can try my best to help
interested parties with minimal help with CVS accounts, access to the
web site and of course, moral support.

Now, I wonder why my computer CD player skips.