[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: bikeshedding by a list veteran
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2006-03-15 0:24:17
Message-ID: 44175EB1.4040503 () acm ! org
[Download RAW message or body]

Celeste Lyn Paul wrote:
> On Tuesday 14 March 2006 17:58, James Richard Tyrer wrote:
>> 2.	Listening to the users and pursuing their issues which I feel 
>> have some merit.  Note that I often do not fully agree with the 
>> users but think that there is *some* merit in what they say.
> 
> right, but we usually ask them when we want to know their opinion 
> that is what user profiling and user satisfaction surveys are for. 
> otherwise we dont involve them in the design process.

Why shouldn't we involve the users in the design process?  I'm not
saying that we should involve them as designers (I'm not sure that we
should involve coders in the design process :-)) but rather we should
involve them as what they are -- as users (aka unpaid software testers).

>>> then adopt an application: introduce yourself the developer(s); 
>>> let them know how much (or little) experience you have with 
>>> usability; work with them for the next 6-12 months (it only takes
>>>  a few hours a week, really) to help improve things. do user 
>>> testing, not just writing of laundry lists of Things That Should
>>>  Be Fixed.
>>> 
>> This sounds good, but it is one of those statements (which we all 
>> make from time to time) which sounds good, but when critically 
>> examined doesn't make much sense.  You are suggesting that all 
>> involvement should be of depth, that people should do many things 
>> on one application.  This is not what I think that usability people
>>  should be doing.  Usability people should work in breadth.  If 
>> they specialize, or are working on, one aspect of usability, they 
>> will develop expertise in that aspect which can be applied to all 
>> apps.
> 
> OSS usability doesnt work that way, primarily because of the Fear, 
> Uncertainty, and Doubt they have in usability and its 'experts'.

Perhaps you are correct that those that write the code do not
understand.  But, working for conformance to standards is not something
which requires usability experts.  I find it hard to understand why
developers don't want help and do not want to have their KDE software
conform to the KDE standards -- but these are the thoughts of an
engineer not a self taught hacker.

Note what I perceive as the difference in cultures here:  The engineer
takes pride in the project while the hacker takes pride in his work.
This is a very large difference.

> the absolute best way to go about and get something done is to create
>  a relationship with the developer[1], get to know the project, and 
> then *WORK WITH THE DEVELOPER*[2] and help them in the design 
> process. i havnt seen it work any other way.

This is not a good situation.  I could go through the whole project and
compare the menus against the standard and send everyone an objective
report in six months.  I'm not saying that I am not willing to work with
the developer but I really have no idea how to "develop a relationship
with the developer" except for a relationship based on working with him
on the product.

> [1] not all developers are interested in usability so of course you 
> would need to first find someone who is indeed interested in your 
> help.

Then why do you call such hackers "developers".  They are just Danil
Dotsenko's type 1 coders -- they will never be real developers or
software engineers.

> [2] developers really dont appreciate getting a suprise report from a
>  random 'usability expert' tearing their blood and tears apart in a 
> few pages of tree pulp.  its a really good idea to contact them 
> before you do a review, its good client relationship and you need 
> background information anyway

And this is where the engineering culture and the hacker culture have
the greatest conflict.  An engineer would regard a report telling him
exactly what was wrong with his project and how to fix it as help.
OTOH, hackers seem to take this as a personal insult.  I remember that
when I first started on the project that I sent a developer such an
e-mail telling him exactly what I thought was wrong with his app and how
it needed to be changed so that it would work.  He reacted very
negatively till 2 or 3 days later he realized that I was only trying to
help and that what I had told him was helpful.

Developers, perhaps, shouldn't expect *random* usability reports, but 
such reports should be made and developers should expect to receive 
them.  I agree that they shouldn't be random, but the informal way this 
project is organized is always going to result in such reports being random.

>> Regarding my #1.  Fixing the little things is the way to polish the
>>  rough edges in KDE, but developers always seem to try to talk down
>>  such suggestions by stating that they are just small issues. Makes
>>  no sense to me.  A lot of people working on little things will 
>> result in a large improvement.  Usability *is* about the little 
>> things.
> 
> yes, but your little usability things arnt as important to the 
> developers are they are to you.

But in the aggregate they are important to the project.

> they are probably sitting on a pile of bugs which cause their 
> application to crash,

This is really a fallacious argument with a mature app.

> so unless you make the change yourself a cosmetic change isnt high 
> priority.

I am more than willing to make the small changes myself and to work with
others in making them.

> yes, usability is important, but making the damn thing run is much 
> more.

But after the 'damn thing' runs, then usability, and polishing other
rough edges should be important.

>> I also think that there are some things that developers need to 
>> understand about usability.  Part of this is the need for 
>> developers to accept higher software engineering standards. 
>> Actually, it is about accepting standards.  Usability standards are
>>  about standardization. Developers that can not accept this will 
>> always be just hackers -- they will never become software 
>> engineers.  Yes, everyone can contribute to designing the standards
>>  but they everyone should follow them.
> 
> the developer have enough to have to know in order to do their job 
> without needing to get a degree in psychology and design as well. 
> last time i checked, it wasnt a requirement to be a programmer

I interject here a little thing I learned in engineering school. 
Knowing how to write code is not sufficient qualification to be a 
programmer or a developer.

> and thats why you have people like usability engineers, user 
> interface designers, and information architects.

> if youre a jack of all trades you will be an expert in none.

So, you agree with me that somehow we need to have a division of labor
-- that those that write the code shouldn't do everything.

-- 
JRT
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]