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

Vincenzo Ciancia ciancia at
Thu Jul 23 16:17:26 UTC 2009

Il 23/07/2009 15:28, Sebastien Bacher ha scritto:
> On jeu., 2009-07-23 at 13:40 +0200, Vincenzo Ciancia wrote:

I agree with the issues you raise. Let me see if I can even be propositive.

> 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)

Fact 1: need for an authority, and maybe a democratic one

 From the above, I'd say that we need an authority to decide that we 
will not scroll on the destko^H ahem, to put an end to endless 
discussion. What I would like to see is turning endless discussion into 
creative and constructive force.

I would consider the ubuntu usability team(s) but in my dreams of 
democracy I would also love some sort of a "popular jury" that can 
influence in some way the authority. Also because I am not going to 
become an ubuntu developer for lack of time :)  But most important, 
because democracy will mean less "dictatorship feeling" hence less 
endless discussions.

What importance to give to the democratic part (from 0 to 100% of the 
decision power) and how to select people (perhaps from the team of 
proposal 1 below) does not belong to me.

But there is an obvious problem: how can one be sure that decisions will 
be accepted? Example: I myself endlessly discussed the pop-up of update 
notifier. I still hate the idea but in the end I had to accept the 
authority princple like everyone else. Here comes a proposal

Proposal 1: a new code of conduct for develpers and bug reporters, and a 
new team

Let us design all together a new code of conduct, and create a new team. 
The team will have a set of bugs (assigned? separate bug tracker? just a 
tag? too early to say this) on which they discuss and work. The team 
will not have decision powers by itself (that's the authority which is a 
separate concern) and the condition to enter the team will be only to 
sign the code of conduct.

The code of conduct shall be oriented to principles such as

- no endless discussions, but try to accept a reached agreement even if 
you are not pleased by that (I am one of the biggest culprits here :)).

- no underestimation of the person reporting the bug or discussing. 
Members of the team are supposed to know what usability is, so if at a 
first glance it seems they are saying something stupid, perhaps a second 
look is needed. Acting like the person is a newbie who needs technical 
explanations about why the behaviour is that way will only create 
endless discussions.

- trying to identify common guidelines, as if all bugs reported were 
also in the whole ubuntu. E.g. it *should* not make sense to decide, in 
the same team, that rhythmbox will quit when one window is closed and 
banshee will not (sorry if the example is related to bad memories <g>), 
even if the argument "we will not go against upstream developers" may in 
the end be adopted in corner cases. Consistency of the desktop will be a 
good argument to avoid endless discussions.

- whatever you like

> 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

Therefore the decisions may be taken by somebody else as I suppose it is 
already happening in ubuntu

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

Therefore it is worth to create a separate place for discussion among 
those interested in usability, as you note below

> - 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 is out of scope IMHO; I don't have a clear vision on who should 
talk to upstream and on when it's just better to leave things as they are.

> 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)

That would be lovely.

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

Agreed and also:

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

agreed and also:

> 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?

agreed, so

Fact 2: lack of manpower

we need manpower to fix bugs

Proposal 2: mentoring as a driving force

Suppose I had good coding skills, and wanted to try to fix simple 
usability bugs. Then I apt-get source the package, start hacking, and 
get lost. That's because I don't know e.g. the huge gnome architecture. 
Therefore, I try to delegate to the gnome developers. But they have 
something better to do. But I can't do anything, since I can't find my 
way in the code.

In the past, I tried sometimes (you were on both the bugs I can remember 
of) to ask for suggestions about the code *on* the bug report, in the 
hope that expert gnome developers were reading and could give advice. 
But it just did not happen. Instead of trying to guess the reason, I 
would suggest that we give a much more prominent role to mentoring! So 
let us consider the eventual discussion forum about usability that I 
mention above, where all the member sign the relevant code of counduct. 
I would expect many developers to be part of the forum for the sole 
purpose of doing some quick mentoring.

Part of the code of conduct should then say

- no impatience w.r.t. mentoring: you may get a very rough suggestion, 
put your hands in the code, find that you need more help, ask for it and 
receive it after 6 months. This is unavoidable. But if we all put our 
manpower under the direction of skilled, but busy, developers, we will 
gain skills ourselves.

For me, the complexity of gnome is really a barrier. With a little bit 
of advice I could try to fix problems myself and then would learn more 
about gnome, and then one day start advicing and so on.

But not in the next month, because today I received news that will stick 
me to my chair to do my "real" job on something not so easy :(


More information about the Ubuntu-devel-discuss mailing list