Reporting usability problems, and an example that I'd like you ALL to read
ciancia at di.unipi.it
Thu Jul 23 12:40:55 BST 2009
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
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
> 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
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
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
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:
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.
More information about the Ubuntu-devel-discuss