New activities: the Gnome Improvements Infrastructure

[zinie cs unibo it (Enrico Zini)]

Hi everybody!

Besides the Gnome UI Guidelines, there are some other activities that
could be done inside the Gnome Usability Project.  Here I try to describe
at least a couple of them, with a personal declaration of intents for
bringing them on.


 * The Gnome Improvements Infrastructure

 Goals:
 
   Big Free Software projects like Gnome are made of a great number of
   individuals (or groups of individuals) contributing in their area of
   interest.  This means that the Gnome community is made of many
   subcommunities (projects, teams, developers of an application, users,
   whatever), working for different goals (improve Gnumeric, make Gnome
   accessible by blind people, write a curriculum vitae with AbiWord,
   improve the Panel so that everybody can use it, translate everything
   possible in Latin, etc.), inside the Gnome umbrella.

   The goal of this project is to build an infrastructure to promote and
   assist the interaction between these subcommunities.
   This does not mean that users have to become developers, developers
   have to become usability experts and usability experts have to learn
   Latin, but that for each subcommunity the infrastructure will take care
   of gathering data and providing reports in the way that is most
   suitable for its users, and most useful to the other groups.


 First outline of what the infastructure could (and should) include:

    - A system for developers to describe what they are doing, be it an
      application, a library, or whatever. Let's call whatever they are
      doing an artifact.
      
      For the interests of the Usability people, it could be interesting
      to know:
       - the artifact's main goals
       - the artifact's target users
       - typical use cases of the artifact
       - problems intended to solve with the artifact
       - environments where the artifact is intended to be used
       
    - A system for a user to give feedback on his interaction with a given
      artifact.
      
      For the interests of the Usability people, it could be interesting
      to know:
       - the user's personal profile (if feasible)
       - what problems were intended to be solved using the artifact
       - what problems were solved and what problems were not
       - for problems that were solved, how was the experience in terms of:
          - efficiency
          - intuitiveness (or difficulty to figure out how it had to be done)
          - agreableness
       - in what environment was the artifact used
      
      For the interests of the artifact developer, it could be
      interesting to know all of this (to compare it with their intentions
      and increase awareness of his users community), plus the answers to
      some questons of his own, like "what is the next feature you'd like
      in this application?" or "what is the part of this library that is
      most cumbersome to use (if any)?"
      
    - A system for the users to report problems on-the-fly:
      "I've been staring at this dialog for five minutes without
      understanding what I'm supposed to do, and the on-line help just
      tells me to 'complete the dialog and press Ok to continue'.
      I'm lost. How do I tell people about this?"

      A Usability Bugzilla Applet could be written using the Accessibility
      Toolkit to identify the GUI item where the user got lost, compile a
      form and submit a bug report to the developers and the UI people.

      This could be expanded for on-the-fly reporting of translation
      errors (and corrections) to the correct translation team and
      reporting accessibility problems.

   
 Plan of action:
 
    0) Get feedback on the project in the usability list, and radically
       change everything that's written here
    1) Start with few subcommunities: "application developers", "gnome
       users" and "usability people" would be enough for a useful start
    2) Decide what data would be useful to gather and report to each group
    3) Design the database to hold the data, and see how it can integrate
       with others facilities already in place like Bugzilla or the Gnome
       application database
    4) Study what interfaces would be the better ways for each
       subcommunity to access to the data
    5) Implement and deploy
    6) Get feedback, improve, include other subcommunities, conquer the
       world.
    
 People involved:
    
    At the moment, just myself.  I'm interested on working on this and I
    plan to contribute a lot.  Plus, from about september I plan to do it
    as my master thesis at the university, so I'll be very active on it.
    In the meantime, I'll do what I can.
    If some other people are interested on it, development can start right
    now, else I'll just keep discussing until I'll start working at the
    thesis.


Phew! This mail has got quite long, and I hope you've been able to keep
reading until here.
It's time for a pause, however, and I think it's better to discuss the
other activity I'd like in the GUP in the next mail.


				Ciao! Enrico

--
GPG public key available on finger -l zinie cs unibo it