The stupid toolbox
Aaron J. Seigo
aseigo at kde.org
Mon Mar 3 21:28:40 CET 2008
On Monday 03 March 2008, Celeste Lyn Paul wrote:
> > b) can you propose a solution for the "we don't have people testing on
> > touch screen" problem?
>
> buy me a touch screen :P
me first ;)
> (This is a problem in itself. There are pen-based tabletPCs and mobile
> phones and there are touch-based tabletPCs and mobile phones. With similar
> yet distinct interaction patterns..)
indeed.
> > and again, i humbly submit that this is people saying "i don't like it"
> > for purely aesthetic reasons and then cloaking it all in a bullshit
> > usability argument that ignores real usability issues. so, again, let's
> > concentrate on fixing the aesthetic issues, which will innevitably crop
> > up on devices as well so we may as well address them now.
>
> So what's more important to you? usability or aesthetic?
both. imho the aim should be to find a maximal point of the two combined.
> There are always tradeoffs and they seem to only go in your direction.
i'm not sure that reflects the history of changes in plasma. i'm here to
attempt to help us all keep a certain direction and a certain level of
quality. but i'm far from the first or last word on every discussion.
that said, i am allowed to have an opinion. i will express that opinion. i'm
not going to be censored from engaging in the process. the good news is that
my opinion is quite changeable, just as with everyone else's.
i understand that as the consensus builder, that when i also enter in the
consensus myself i'm viewed with a certain amount of suspicion that stems
from concerns of conflict of interest (e.g. that the consensus will
innevitably just end up to be my input). that's a paranoia people are just
going to have to find a way to live with, since that is not how things work
in reality.
> What argument is
> this anyway? Are you concerned about the usability of the toolbox or that
> taking it away makes it not pretty?
ok, let's untangle this:
the toolbox is there to provide a certain pattern of access to a select group
of actions. for me, it's a usability thing.
for others, it's a set of aesthetic issues. i've heard various
pseudousaibility rationalizations, but when pressed to the facts it emerges
that they are aesthetic issues.
so for me it's about usability. for the naysayers, it's about aesthetics. so
i'd like to address the aesthetics (which we've done several time already;
it's an iterative process wher we fix this issue, then that issue , then the
next.) an example of a past aesthetic change would be no painting the icon in
colour when not activated as it was felt to be too distracting / attention
grabbing in the default passive state. when this feedback was given, i looked
at it and had to agree. so we fixed the aesthetic issue.
to be fair, there were also usage issues that were not purely aeshetic, such
as being able to send the toolbox into an endless jerk-spasm with the
right/wrong mouse movement. we've also addressed those. however, these
challenges related to the actual toolbox mechanism itself, not the usability
issues that the toolbox is addressing.
> You get so anxious when people either
> a) don't get what you're saying or b) don't like what you are saying that
> the conversation spirals out of control before the rest of us can figure
> out what's going on.
let me modify these points so they are more accurate from my POV:
a) people don't get what i'm saying after i've repeated the conversation N
times previously. i do not appreciate going through things time and time
again. not only is it a waste of my time, but in the situations where people
simply restart the conversation on the off chance that the outcome will
change (the "no harm in asking .. again!" approach) it's pretty rude.
b) people decide that it's ok to simply ignore related principles and
therefore don't like what i'm saying. in this case, it's a disagreement
between fixing real issues (e.g. improving the aesthetics) vs working around
problems (providing an option to turn the whole feature off). that's a pretty
basic concept, and when people decide that since it's not convenient for
their immediate needs they'll just ignore it and try and get their work
arounds in anyways ... yeah, that's also a sign of disrespect for the
project.
it comes down to people providing input in a way that doesn't degrade the
project as a whole. yeah, that's not the easy route. i understand that. but
if you push at me to compromise, i'm going to push back.
"push me and i will resist, this behaviour's not unique" - Corduroy, Pearl
Jam.
> I thought I understood the problem but now I don't
i don't think you do understand the problem. that's not really your fault,
imho. the conversation was started by a wrong headed approach to the problem,
which gave it the appearance of being some other problem all together. and so
the conversation spirals outwards into greater irrelevance from that starting
point. and yes, that's frustrating for me to deal with.
> I don't remember seeing anything about aesthetics or usability in this
> problem, only that people were complaining about the toolbox and wanted it
> removed. The issues shouldn't be that they want it removed, but WHY.
YES! that's exactly it. as i said earlier, and i quote:
"i humbly submit that this is people saying "i don't like it" for
purely aesthetic reasons and then cloaking it all in a bullshit usability
argument that ignores real usability issues."
i'm looking for reasons why they want it removed ... and then fix them. and
you know what? there are enough issues out there to address that we're not
going to fix them all today. some will have to wait until tomorrow. just
because those fixes won't come until tomorrow is not a reason to screw things
over now. and that's just afact of life that people need to get cozy with.
> What was the question again?
a) what are the objections people have to the toolbox?
b) given those objections, how many can we address to the satisfaction of
those people?
c) of the remaining objections, how many of them are actually valid, e.g. not
due to a lack of understanding (which can be at least partially attributed to
our lack of documentation and some of the feature incompletness)?
> > (yes, i'm getting a strong sense of deja vu with regards the recent
> > kickoff selection thing, because it's very much the same sort of issue.)
>
> kickoff was an different problem. people were complaining about usability
> when we should have been addressing aesthetic. I (ignorantly) assume when
ok, so what are the usability issues with the toolbox?
i would humbly submit that this is very similar to the kickoff issue with
people attacking a problem with a "path of least effort" approach versus
actually identifying and then solving those problems even if it takes a bit
more thought and effort.
the "obvious" answer that is dead simple in both of these situations is not
the best possible (while remaining realistic) solution. and that's the common
thread here: half assed solutions are going to be viewed dimly next to
solutions that actually fix the root challenges. those offering half assed
solutions shouldn't be put off by that. those half assed solutions often give
us feedback for the direction we need to head in, so they aren't valueless.
they just won't be accepted in their current form. (and repeatedly trying to
push them on me is not going to make me happy.)
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080303/01bdd507/attachment.pgp
More information about the Panel-devel
mailing list