Reporting usability problems, and an example that I'd like you ALL to read

Sebastien Bacher seb128 at
Thu Jul 23 13:28:45 UTC 2009

On jeu., 2009-07-23 at 13:40 +0200, Vincenzo Ciancia wrote:

> triggers the response that I am the only one reporting the bug, then 
> it's not affecting all users, hence it's low priority or even not a bug. 
> I think some of you reading will remember such a circumstance recently 
> :) (Perhaps not so) clearly this is wrong. Usability bugs typically 
> affect ALL users, but all of us need to go on and learn how to 
> circumvent those.

Things are often not as clear as you think, read the list of all the
bugs users suggested as hundredpapercut for some example. The way you
use your computer is often different from the one the next user will use
and you will have conflicting opinions (some users think that switching
workspace by scrolling mouse over the applet is efficient some other
that the behavior is confusing, some will want confirmation to actions
some other don't get why the computer should ask confirmation rather
than just respect the user action, etc)

There is several issues there:

- the people working on packages and softwares are often good to do
technical work but not so good when it comes to take decisions on
usability or design
- the usability issues reported often turn to long arguments between
users not agreeing on the change and those issues are in the middle of
clear technical bugs, it's difficult for usability people to list the
usability concern and reciprocally a high number of usability suggestion
makes the list of technical bugs harder to work with since you have to
find a way to filter those you have no interest in
- the distribution maintainers are not written most of the software
distributed and don't always feel entitled to take design decision on
the software without having it discussed with the upstream authors, they
also don't always want to take the suggestion upstream because they have
no strong opinion on the topic and don't feel they will argue for the
change in a convincing way there

That said we should perhaps have a different location where those
suggestions can be discussed and moved to the bug tracker once a clear
design change is approved (ie rather than adding ubuntu tasks to each
hundredpapercut next time only add one for things which have been set to
triaged and have clear suggestions which have been reviewed)

> upstream. Guess what? Nobody cared to reply. I don't know if my comment 
> triggered any attention but clearly this issue is not considered 
> interesting enough to post a reply, even if it's present in ALL the 
> ubuntu installation. That's 100% of the users.

Did you consider that only few people are working on this software
during their after work hours and they can't just managed to deal with
the flood of issues and suggestions sent their way?

The issue there is no that "nobody cared" or that "the issue is no
considered interesting enough", it's just than there is hundred of bugs
open on this component and not enough people working on it to handle
those correctly. 
Note also that bumping settings for bugs will not make a difference in
the fact that the limitation is simply due to a lack on manpower to work
on those.

You seem to argue in favor of welcoming higher number of suggestions and
bug reports, that's good but how does it solve this workload issue? What
is the use of having thousand of good suggestion if nobody is working on
making those happen and the quantity is just discourage the few volunter
to have a look to the list because they know they can't deal with all
those? Wouldn't it make sense to have a lower number of suggestions but
focused on what would really make a difference in the user experience, a
list that would be manageable for people doing the changes?

Sebastien Bacher

More information about the Ubuntu-devel-discuss mailing list