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

[Vincenzo Ciancia]

Il 23/07/2009 12:05, Andrew Sayers ha scritto:
> Hi Vincenzo,
>
> You might have more luck if you describe your changes as feature
> requests.  Whether or not you personally think they're bugs, calling
> them new features should avoid the "always been that way" reaction from
> developers.

Hi Andrew,

if I call them features, when they are bug, the reply will be that they 
need to be blueprinted :) And in any case the priority is doomed to be 
low, and so the interest of the developers. Sometimes it's just a matter 
of changing a wrong string, and maybe the problem is to find which 
package is the responsible.

Now, this can be argued, but let me reply to the second part of your 
e-mail and then I will give an example of the issues I am talking about. 
The example is clearly not a feature request, but as Sebastien said it 
was difficult to fix and with no interested developers. But read it for 
more.

>
> You might also want to try helping out with the "improved me too"
> blueprint: https://blueprints.launchpad.net/malone/+spec/improved-me-too
> - useful "me too" data would let you argue that behaviour is non-obvious.
>
> 	- Andrew
>

I wanted to know about such a blueprint so thank you. However in my 
experience this is not going to help with usability problems.

Most of the users don't care about usability once they got around the 
issues. Very often I am alone in requesting a change. This in turn 
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.

Often, this results in users starting to fear to do obvious things such 
as touching their mouse, when a certain window is opened. This is a 
totally istinctive kind of reaction. We are learning machines and being 
punished because we e.g. touch the mouse and a certain program may do 
something annoying results in us learning not to touch the mouse in that 
case. This is typical in windows, and this is probably what they call 
the "mac user experience", that is, not having to fear touching our 
computer, or e.g. clicking on a menu, because it works in the expected 
way. Gnome is very advanced in this respect, but there still are 
problems, obviously.

EXAMPLE:

When I click on the gnome panel menus, I am constantly in a "be careful" 
mode, because I know that if I start a drag by mistake, I can't press 
ESC to cancel.

In the past, I have been punished because I started dragging. E.g. it 
happened that I started copying some huge remote directory inside the 
desktop without noticing it, eventually running out of disk space. Now 
it seems that the bug is "fixed" in karmic by disallowing dragging. I 
don't know if this is a wanted behaviour or just the sum of two opposite 
bugs. But it seems the latter, unfortunately, since I actually see the 
drag start and be immediately cancelled, which is also very irritating 
when you actually want to drag something.

That's a bug nobody cared about for years. I reported that in 2006, 
Sebastien (who is my best triager :)) told me it was already known 
upstream.

Recently I found out a clue on why this happens (it was an open question 
since several years). The problem is that the panel does not  have the 
keyboard focus when one is dragging, so pressing ESC is captured by the 
currently focused window. You can observe this by opening a modal dialog 
closeable with ESC in a program and then starting to drag, and press 
ESC. The dialog disappears. I reported it, BOTH in the ubuntu bug and 
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.

If the priority was higher, perhaps somebody would have at least replied 
to my comment? I don,t know, but it's a fact that the priority can't be 
higher, because it's a "stupid" problem, not a crasher or a release 
blocker. This is a vicious circle that is not leading to anywhere. We 
need to handle usability in a separate way perhaps, but this is 
something that canonical and ubuntu have to consider, not me.

Here is the bug:

https://bugs.edge.launchpad.net/gnome-panel/+bug/69012

You can see it's old, it's low priority, and it has been rejected as a 
papercut. You can also follow the upstream link and see my comment stay 
there unreplied. That's frustrating. Consider that I kept the problem 
for 3 years in a corner of my mind, and when I saw a clue about the 
solution, I hurried to you to tell you that. This is manpower for free, 
or for a better ubuntu, which I am happy to have as a salary :)

Nothing personal, you know that. And 2 weeks is a short time for a 
reply, I know also this. But I can't know how long the reply will 
stagnate without me going around IRC and mailing lists to bother 
somebody about it. Like I am doing right now, btw.

Vincenzo