Re: A call to action



I just want to say that i am in totaly agreement with you.  It is
unrealistic to attempt to come as an outsider to a project (being a person
who has not been intricately involved in the daily labour of love that is
coding on a free software project) and tell the coder what is the "more
correct" way of doing things on an individual case by case basis.  This
really is micromanagement from a non knowledgable outside source, and will
not be welcomed in a project that is inherently run by ego gratification
and pleasure (as well as it make work in a work situation).  At the same
time there need to be broad, well understood and clearly specified
standards that are genereally aggreed on to provide a consistant, pleasant
and workable user experience.  It seems clear to me that the most
efficient way to bring "those who know" about UI issues, and "those who
do" the coding together is through an involved standards process, most
likely in the form of a standards document.  While sometimes coders will
accept advice on how to tweak a dialogue to make it better, the reality is
that it more likely will cause some degree of ego clash, and hence less
effect than would a prior agreed apon standard.

- Joschi

 > 
> Just a comment on this thread, from a developer who became
> disillusioned and estranged from his internal ui design process.
> 
> A bit of background: I spent the summer working for MIT Athena to
> integrate GNOME with Athena. This involved making GNOME build on all
> the athena platforms (IRIX and Solaris being the problem ones), making
> GNOME play well with some concepts that exist only on Athena, and
> porting legacy apps.
> 
> There was a member of our team who took it upon himself to work on UI
> design, and had qualifications in that area. Outside our team we also
> worked with two usability specialist who were going to set up formal
> testing of all sorts of things.
> 
> However the other "real" developer and I (who were doing, in our
> opinions, the actual work) saw our opinions of these people degrade
> quite quickly. And while there were some questions of competence, the
> real issue was in the style of communication.
> 
> In general UI people, especially in GNOME, talk to developers about
> small parts of their project that are already written. Frequently UI
> design groups like the hitsquad are asking developers to rewrite a
> great deal of code. And, most importantly, the UI designers seem to
> hold opinions for a fleeting moment compared to the ammount of time it
> takes to implement them.
> 
> The solution to this problem, it seems to me, lies in producing a
> document similar to the Apple Human Interface Guidelines. This will be
> a significant document which covers 99% of UI design decisions, and in
> each and every case gives an unambiguous GNOME solution to the
> problem. Whether this is written by committee or by star chamber or
> any other method doesn't really matter. It has to not suck in any
> clear way, and once it is done it has to be followed and enforced.
> Once you have that, it becomes possible to say that (1) all developers
> of official GNOME apps should follow the guidelines and (2) when the
> guidelines are ambiguous people should ask a specific body rather than
> just making somethin up.
> 
> just my opinion,
> tibbetts
> 
> -*- http://www.mit.edu/~tibbetts -*- finger tibbetts monk mit edu -*-
> 
> _______________________________________________
> gnome-gui-list mailing list
> gnome-gui-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-gui-list
> 

_______________________________________________________________________
Josh "Yoshi" Steiner - josh xiphoidprocess com - http://eds.org/~joschi 

Xiphoid Process Records - http://xiphoidprocess.com
San Francisco based electronic music.





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