Re: [Usability] Reaching Users

[Karl Lattimer <karl qdh org uk>]

On Tue, 2009-12-08 at 11:27 +0000, kerberos piestar net wrote: 
> Firstly, I think bugzilla has no place in any discussions of  
> usability.  Bugs are absolute, and bug tracking software is designed  
> for people to report, and then developers to fix.  Usability issues  
> are largely subtle, subjective and often require some debate.  While  
> the bugzilla approach may apply to minor issues 'Why can't I use my  
> scrollwheel here, etc' it is simply unable to handle anything that  
> could be considered innovative or new.  It is my belief that bugzilla  
> will never lead to a substantial improvement in software - If you  
> placed Windows 95 on a bugtracker would it fix the fundamental issues  
> with usability, security and stability?  Architectural and large  
> ranging issues are simply a bad fit for bug tracking software.  It is  
> also intimidating and works in absolutes, while usability doesn't -  
> it's more of a discussion.  I would be very hesitant to post anything  
> non-trivial to a bugtracker - it's simply not the place.

I largely agree with this, making a usability improvement via the bug
tracker means the maintainer or developer needs to understand your
complaint, agree with it and find the time to implement it. 

This isn't ideal

> Barrier 1: The majority of Linux distro's (Ubuntu and Suse to name  
> two) have no place on their forum for discussing ideas or engaging the  
> community - it is all one sided 'support'.  There are plenty of forums  
> for discussing how to get your sound card working, but nowhere for  
> discussing a way to make fixing it yourself simpler.

This is an idea destined to fail, using forums as a means of managing
usability complaints means a developer needs to monitor that forum. The
likelihood of this is minimal. What you end up with in the end is a
GNOME ToPaZ style bikeshed where nothing really comes out of it. 

> Barrier 2: The lack of any feedback forums above is understandable in  
> context.  The main distro's package the upstream apps and release them  
> - they are not directly responsible for problems in Gnome's etc  
> codebase.  As a result there is no real way of knowing who made or  
> maintains which program or module to suggest improvements to.   
> Identifying and reporting anything non-trivial is in itself  
> non-trivial.  Unless you want to blog about it, there is largely no  
> venue for feedback.

I think this is a separate issue, one which is the responsibility of
downstream to correctly address the concerns of their users to upstream
developers. However the point that it's difficult to discover a
developer or maintainer which will be capable of acting on a suggestion
is difficult to the average user. Also developers don't want to be
bothered with every minor complaint a user makes, there needs to be some
kind of filtration. 

> Before any real progress can be made on usability and improving the  
> marketshare of Gnome (and Linux as a result) these issues should  
> largely be addressed.  Users need a place to say why they don't like  
> something without being called idiots or trolls.  There is very little  
> point in having a community contributed OS that the community cannot  
> contribute to.  Most users can contribute ideas after all, but few can  
> contribute code - which seems to be the sole focus.

I think part of the problem is a core of hackfest attendees define the
direction and design without considering the alternative suggestions of
the users. Design by committee creates either a fertile ground for
bikeshedding, or a way of those involved in the committee scratching
their own itches rather than empathising with users and trying to
scratch their itch. 

Now up until recently the itches of developers were largely the same as
the itches of users, e.g. wifi working, file management and vfs for
network shares these kinds of things are very important but now we're in
a situation where most things just work... This is where we need to
start looking at a core usability team which can take a series of
complaints about usability and turn them into proposed design solutions.
The solutions would then require consideration and development until the
needs of the many are met, rather than the needs of the few - as per
"engineers design user interfaces for engineers, not for users" 

The pattern library as suggested recently is a good first starting
block, as it allows usability and user experience experts to define a
common baseline of best practises. From there it becomes a matter of
listening to users, performing usability tests and designing user
interfaces by means of creative visual arts rather than structured
engineering... i.e. taking the apple approach to user experience design.

anyway, that's my 2c

BR,
K