[Libreoffice] FW: [PATCH] Introduce HideDisabledMenuItems style setting

Thu Apr 28 08:43:23 PDT 2011

Hi all!

Michael, I get the same perception as Christian when reading your mail.
In fact, I didn't see any constructive criticism how to avoid such
situations or any explanation why our understanding of the patch is
wrong. So at the moment - nothing is resolved, it even gets more
complicated.

I'd like to ask you whether you have experience developing features for
end-users - have you? I'm thinking about stuff that affect the
interaction ("the dialogue") between end-users and computers. This is
quite different to the work "under the hood" (which is always good) -
not only since we compete with other office suites in the market.

Since your mail indeed sounded a bit "ruling", I think the link to Jakob
Nielsen's blog posting covering usability maturity fits well. He, by the
way, was one of the first to promote usability and to think about
"people" when developing software. A good reading (also fits on FLOSS
communities):
http://www.useit.com/alertbox/maturity.html

So, at the moment, your mails sounds like "Stage 1" or "Stage
2" (problem: this is a software mainly intended for end-users). Maybe
you think differently, but in any case, I'd like to help (in the long
run) to improve the quality of the project's outcome. But, this also
needs some agreement from your side.

Another few remarks ...

Am Donnerstag, den 28.04.2011, 13:15 +0200 schrieb Christian Lohmaier:
> Hi Michael,
> 
> On Thu, Apr 28, 2011 at 12:31 PM, Michael Meeks
> <michael.meeks at novell.com> wrote:
> >
> >        Firstly - progress is not well served by hindering, and slowing down
> > people committing patches - yes, some things may break when things are
> > changed, but then - the fixes should be able to get in quickly too.
> 
> It isn't a fix when it breaks common HIG behaviour,
> All was asked for was a clarification of what the patch actually does.
> This is not hindering in any way.
>
> >        It -is- the end of the world to de-motivate, and loose developers
> > contributing code; we need to presume contributor sanity until proven
> > otherwise, and merge unless we know it is certainly wrong.
> 
> No, With this "We don't care about what the user sees as some
> developer wrote a patch" you tell UX, QA, and regular users to fuck
> off.

I second that. Besides users, this also has impact on those who provide
support - in many cases it'll be required to explain strange behavior
several thousand times (related user base size) and to document stuff
why it doesn't work as intended. So wouldn't it be better to implement
it correctly right from the beginning before causing others a lot of
work? (I assume a "Yes".)

So, I'm fine with saving development effort because you might have
limited resources - but please have a look at the other teams who might
have similar problems. "We merge unless ... we know it is ... wrong" is
the right statement to de-motivate other contributors (really, there are
people that contribute something different than code).

> > Shouting about the potential loss
> > (though in fact it is not lost), of a minor feature, available only to
> > expert users and sysadmins, does not seem proportionate to me.
> 
> Yes, and it is always the developers who don't actually use the
> software who then come with this argument "Why would anyone cry about
> loosing this feature". Sorry, but I absolutely don't agree with this.
> 
> The patch might do what is no problem, but when it really just hides
> instead of greying out inactive (as opposed to removed-by-sysadmin)
> functoins, then this is not a "minor feature".
> 
> Again: A simple clarification and all is fine. But you then just jump
> in with "read the code" isn't helpful.
> 
> >        Also, by delaying developers with lots of noise, quite apart from
> > de-motivating them, we waste opportunities for using their time for
> > other improvements to the user interface.
> 
> Bullshit, sorry. I cannot hear this anymore. All the noise would be
> gone in an instant if people would bother to actually answer the
> questions stated.
> 
> >        So - in summary, there is huge danger of de-motivation, dis-couragement
> > and sterilization of the developer community from applying
> > indiscriminate push-back. -Particularly- if it is inexpert push-back. In
> > this case,
> 
> Again Christoph is hardly an "in-expert" when it comes to UX, I don't
> consider myself clueless either.

You are aware what you've written wrote? Let's do some minor
modifications ... then it's still wrong but sounds better from my
point-of-view.

"So - in summary, there is huge danger of de-motivation, dis-couragement
and sterilization of the non-code contributing community from applying
indiscriminate push-back. -Particularly- if it is push-back by
inexperienced developers."

Again, this is wrong - as your statement is wrong. So please avoid such
unhelpful comments.

> > it seems the distinction between a -context- menu and the
> > main menu, that is present if you read the patch (though somewhat
> > missing from the original mail, and the naming sadly) is quite
> > important.
> 
> A simple mail "This patch does this and that, and not what you think"
> would have been enough.
> 
> >        Anyhow - I am sure none of us intend to cause problems, delay
> > improvements, de-motivate developers or end up shouting :-) so -
> > hopefully we can get back to some positive work on the product.
> 
> Sorry, but your mail clearly has the message: We love developers, no
> matter what stupid their changes are, if they can get a foot into the
> door we welcome them with open hands. But we don't give a damn about
> usability experts and users, since whatever they have to complain
> about can be fixed later.
>
> Your smileys don't make it any less harsh.

So, what can we do to improve the situation? There are several ways how
to do this ... a simple and great start could be to ping the Design list
and to get a reply (a short review) by somebody you trust with regard to
UX / usability - before pushing a patch (if this change would have a
high impact on users).

It's just one idea, but it would even fit to the Next Decade Manifesto
"We commit ourselves: to an open and transparent peer-reviewed software
development process where technical excellence is valued".

What do you think? Not to forget, I'm happy if you provide any ideas -
we are currently collecting stuff to clarify how we (e.g.) can support
development best.

The last time we had such a discussion (only a few weeks ago), Björn
wrote a nice blog posting - definitively worth to look at:
http://www.opensource-usability-labs.com/tine20/2011/03/18/designer-vs-developer/

Cheers,
Christoph