Re: How to deal with unwilling devs?

On Wed, Jul 29, 2009 at 5:37 PM, Markus <kamikazow@xxxxxx> wrote:
>
> Not only that, he refuses to do steps of his own to discuss that matter
> further, instead (and I quote) "Celeste may come and discuss about this topic
> on the kde-pim mailing list" which sounds like a pretty arrogant attitude to
> me.

I dunno, reading the way you dropped my name he
a) probably didn't believe you or
b) wanted someone else to better explain the guideline to him.

Also, you didn't really do too good of a job working with him on
figuring out the best way to close/quit windows. He brought up a valid
edge case which had not been discussed. Instead of blindly adhering to
the guideline*, you should have worked with him on a better solution
and seen if it applies elsewhere in the environment and constituted a
change.

* A guideline, which by the way, is in progress and has not been
finalized. One reason for incompletion is because we *haven't*
explored edge cases like the one specified in KDE PIM and because of
systemtray changes in 4.3.

> Now what?

Revisit the guideline and adjust it for the edge case. If the
guideline still holds, then create a better argument as to why the
developer ought to make the change.

On Wed, Jul 29, 2009 at 5:53 PM, Andreas Pakulat<apaku@xxxxxx> wrote:
> Thats easy: Start a discussion on their mailinglist involving usability
> folks. Neither the HIG (note the word "Guideline" in it) nor any person
> can enforce such changes. If the developers think the change is wrong,
> then the app won't be changed - unless the developers in question leave
> the project and somebody else does think the change is ok. Apparently
> Christophe either disagree's with what has been said in the thread or
> didn't read it completely due to the extreme size of it. In either way
> you'll have to convince the KMail authors that having a shortcut for
> quitting the app is needed and you'll have to discuss with them what
> "the app" is. Especially in the case of kmail thats not quite easy as
> Christophe already hinted.

You are exactly right that no one can "enforce" changes. The best we
as designers can do is explain our reasoning well enough that we can
convince developers that our suggestions are a good idea. If we fail
to explain our ideas sufficiently, then we're not really doing so well
as designers.

On Thu, Jul 30, 2009 at 1:46 AM, Markus<kamikazow@xxxxxx> wrote:
> No, it's not. Not even close. Thomas McGuire is the main dev. The name of that
> guy isn't even in KMail's credits window. Other than that: What's even the
> point of a usability team if nobody needs to care?

As Andreas said: "To give advice to the developers and to explain why
a certain kind of GUI is bad for the users. The developer is still
free to accept that or not."

We can't act like gifts from [some deity] who say "do this because I
say so". That attitude simply does not work in FLOSS, and quite
frankly, it doesnt work in industry either. People will care if you
can convince them there is value in what you are suggesting. You
failed to convince the developer, and that's not his fault.

> Why does the usability team run behind every other team? Why discuss a matter
> here first just to have the same discussion again there?

Because not every developer should be required to lurk on the list
waiting for a small bit of information relevant to them in all the
noise? I find this list pretty noisy and *I'm* the moderator. Good
discussions are too easily derailed, but that's off-topic.

So if you want to try this again, the missing piece is communicating
with the developer about his concerns about the proposed change.
Figure out the reasoning why he likes the current behavior. Other
people mentioned it might be a technical reason and confirm that issue
and see if that is why he doesn't want to change the behavior. Work
together, don't dictate. Remember that KDE is a *community* so treat
the people involved like friends, not peons.

Also keep in mind that it is possible you can't change his mind.
That's OK too. Just work on something else. If this is something that
gets fixed elsewhere in KDE, then he might eventually change his mind
on his own.

~ Celeste

-- 
Celeste Lyn Paul
KDE e.V. Board Member
KDE Usability Project
www.kde.org
_______________________________________________
kde-usability mailing list
kde-usability@xxxxxxx
https://mail.kde.org/mailman/listinfo/kde-usability