Re: [Usability] Overthinking things.
- From: Jacob Beauregard <deadowlsurvivor gmail com>
- To: usability gnome org
- Subject: Re: [Usability] Overthinking things.
- Date: Thu, 10 Dec 2009 10:44:43 -0500
Note: I may have mixed "Overthinking things." with "Reaching Users".
On Wed, 2009-12-09 at 11:34 +0000, kerberos piestar net wrote:
> Quoting Charline <charline poirier canonical com>:
> The main issue with the community is that they are emotionally
> invested in Linux and the resulting movement so see criticism of it as
> criticism of themselves (and take it personally) causing most attempts
> at honest feedback to result in a flamewar - through no real fault of
> anyones.
I don't believe that criticism is taken personally at large so long as
it's constructive. Some hackers will reprimand you for disagreeing with
them. After I read Javascript: The Good Parts, I thought it was very
good but found that some of my uses of Javascript's syntax that were
discouraged in the book didn't reflect the arguments that were used in
discouraging, so I sent Douglas Crockford an email asking him what about
such and such use cases? I got a response saying that I can write crappy
code if I want to. In GNOME, at least, I haven't found that attitude
pervasive, though it isn't rare.
If someone rants it can easily be transformed into something
constructive, though sometimes rants can be taken as an insult rather
than a rant, which is where a flame war can begin. Generally most rants
have some substance (to begin with) that can be turned into something
constructive.
Community needs to be placed before everything else.
> In seriousness I would suggest some form of project to reach out and
> find out why people are not using Linux - at the moment the attention
> seems to be on listening to the happy people, which seems a bit
> redundant. If anything it would inject some realism into the debate.
I gave my dad a computer that I loaded Linux onto. He complained that he
didn't know how to use Linux, swapped it out for Windows, downloaded a
virus, and now wants to go back to using Linux again. His primary
concerns are that he can't use Netflix, and that OpenOffice doesn't save
in a format that MS Office uses. The former is complicated, and the
latter is inaccurate, but saving a file in a format other than the
default one is something my dad doesn't really understand. In essence,
Average Joe Developer would mark this as invalid whereas a usability
expert would try to find some way to correct the misperception.
I think this is the kind of bug where filtering for developers would
make sense. Maybe bugs marked as invalid and worksforme should take a
different status than "Closed" for this reason.
On Wed, 2009-12-09 at 22:50 +0800, Lincoln Yeoh wrote:
>
> If the system requires users to convert a _valid_ "stuff is broken"
> report into multiple bug reports, before broken stuff gets fixed,
> then it just makes things less likely to be fixed. The users might
> actually have alternatives they can use, so they go away and stuff
> stays broken. The developer may feel that's fine with him/her, but it
> does not help the project.
I break up other people's bugs at work as a developer. It's not that big
of a deal.
On Wed, 2009-12-09 at 15:41 +0000, kerberos piestar net wrote:
>
> I seriously doubt there would be a lack of volunteers to sort, track
> and present such
> information based on such discussions. I can almost see (I shudder
> to
> use this example)
> an X-Factor style judging system where ideas and changes are
> discussed, and if accepted
> merged into the actual project plan (or submitted as a 'good
> idea').
> Provided the judges
> knew what they were doing that would act as a filter between the mob
> and the devs.
A lot of bugs are triggered by the environment in which the program is
running. I had Empathy crash on me every time I tried to open ##php on
FreeNode with an I/O failure. I was using ecryptfs, and the history file
I had for the ##php channel became corrupted. The developers on
#telepathy said that though it was a quirk in ecryptfs, that telepathy
should have better handling of I/O failure.
Now imagine the bug report: "Empathy crashes when I try to open the
##php IRC channel"
There's no way to determine what may have been causing the problem. A
dialog with the user is required to develop good software. Filtering it
isn't really all that simple for this reason. I believe IRC and mailing
lists would be better places to send users than a bug tracker because it
implies that dialog. The problem with IRC and mailing lists for this
purpose is that they're harder to track. Does Bugzilla accept email
dialog?
With usability, it's probably easier to intercept and pass on, though
there are some cases where the user is sure it's a bug and the developer
is sure it's not where it would be a benefit to have someone to take
perspective to both sides. Some are invalid. Some require further
dialog. I would suggest adding a "Review" status to bug trackers where
things need further elaboration. Maybe not the best idea, but it removes
the black and white of open/closed.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]