Re: GUP Proposal Organization



On Tue, Jul 31, 2001 at 12:30:11PM +0200, Huib Kleinhout wrote:

> 1) A bugzilla-like system where gnome USERS can fill in a simple form to
> tell what they dislike/like to see more. 
> With such a system Gnome can be very 'open'. Lot's of users can't/don't
> want to code or discuss on gnome mailing lists. They just have a simple
> complain/problem. 
> Althought thorough usability tests (like sun did) are always needed
> simple user feedback can at least -detect- many problems.

This reminds me of an old proposal I made on the early days of this list;
too bad I can't discuss about it now because today I'm leaving for the
holidays.

Anyway, it's something that could be my master thesis for the university;
it could be a good chance to have a look at it while I'm away and come up
with some criticisms/proposals/requests that I'd be happy to read when I'm
back.

Being a master thesis, I'd put quite a lot of effort on it.  However, I
need to know if there's enough interest to bring this on, or if there's
something more useful to do within the project.  Besides the guidelines,
of course.

Enjoy the meeting!

Bye, Enrico



 * 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.
    

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini (Unibo) <zinie cs unibo it>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]