The stupid toolbox

[Aaron J. Seigo]

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