Re: [Libreoffice] [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...)

Hi Michael, all,

At first I want to thank Sébastien not only for his work, but also for 
being open to the discussion here, even if this means to delay the final 
inclusion of his patch.

I tried to calm down for more than one day by now, but as Michael 
repeated his position, I have to reply now.

Sorry for not being able to react as positive as Christoph - perhaps I 
didn't spend enough time in UX/UI to learn to live with this kind of 
disappointment.

*Short version:*
If Michael (as one of the most relevant developer in our community) is 
right with attitude against non-coding contributors and if this is the 
official position of the LibreOffice project and The Document 
Foundation, I will not keep on spending my spare time and dedication to 
this open source project any more.

When coders are allowed and encouraged to do their changes regardless of 
the voting of the relevant experts in areas their code contribution 
touches, we come back to a two-class community where the broader 
community is not involved in decisions taken by non-experts but 
influencing the entire community and it's public standing.

I will no longer be part of such a community.

*Long version:*
Michael Meeks schrieb:
> Hi Sebastien,
>
> On Tue, 2011-03-08 at 09:09 +0100, Sébastien Le Ray wrote:
> > this simple shadow patch has generated a long discussion on
> > Libreoffice-design. Some people don't like the color, some people don't
> > like the amount of blur, some people want no shadow at all, some people
> > want a "4 borders" shadow.

You're right about the different personal feelings, but they are not a 
decision of the LibreOffice Design Team.

For a developer interested in working on a certain topic it would be 
easier to get a final voting like
"The Design Team asks you to add a 8 px wide blurred shadow in grey 
transparency to all borders of the document. If the zoom factor reduces 
the space between two sheets to less than 16px, the overlapping areas of 
the shadow should be cut off. This should apply to every area of 
LibreOffice, where document borders are visible, namely Writer, Impress, 
Draw, XML forms [others not yet searched for]."

But such a specification is necessarily a result of some kind of 
discussion, if there is no single decision maker. As we don't want such 
single person decisions, this list is "talkative".

> > So here is a second patchset that tries to
> > address the first three critics :

I hope you understand now, that the comments have not been meant as 
critics, but as part of the decision making process in the Design Team.

Perhaps we need a different way to interact with developers, keeping 
them out of our processes and coming back to them with the results. This 
could be the relevant bug-report, a mail on the developer list or any 
other structure.

But at least at the moment, where we are a young group working on our 
basic structures, this takes some days...

In my eyes it is very important to show developers how the Design Team 
works, giving them background information on important UI and UX points.
>         So - firstly, this -sounds- like an interaction disaster :-) I hope it
> is not of course, but it looks like this:
>
>         We finally get a competant, enthusiastic, motivated developer -
> actually fixing our horrible user interface problems: and he does some
> great improvement - and our design guys apparently emit a long stream of
> complaining left and right ! That, if true, is hard to excuse.

And I hope you don't mean it this way, but it sounds like this:

A team of individuals works hard to establish a common visual design for 
LibreOffice. They spend hours and days of hard work on this topic and 
their work seems to be respected by the community.

But when a developer wants to improve something on the UI and informs 
the Design Team about this topic, he is told by one of the leading 
developers in the community not to care any sh... about the Design Team...
>         We need to greet new guys with a torrent of encouragement instead I
> think.

Right - but these new guys are not only developers, but other community 
members like designers and UX experts too.

I don't read your mail as encouragement to them :-(

> I hope I'm wrong - I don't read the design list because I can't
> interact there [ Reply-To: mangling sucks ;-]

That's your personal opinion - everybody else can subscribe to the list 
and avoids offlist communication and duplicated mails...

> - but this paragraph
> smells problematic. I think we need to remember that the perfect is the
> sworn enemy of the good - so lets get good across the code, before we
> get perfect.

Of course this statement is right - but working on a topic without 
respect to the specialists is even worse than trying to be as good as 
possible.
>         Perhaps we should move all programmer interaction on design / UI topics
> onto this list, or a new Freedesktop one - and leave the 'design' list
> as more of a 'discuss' type forum.

You refer to the libreoffice@freedesktop list as "this list".

This is the easiest solution for developers, but quite hard for 
designers / UI / UX experts to find out the relevant tasks among the 
hundreds of totally irrelevant mails for them.

Once more you define "discuss" as opposite to "work". The design list's 
topic is as well working as decision making. Disregarding this team 
leads to the feelings you evokes not only by me...

>         Sebastien, I hear the complaints; and I read your nice patches (and
> just pushed them[1]), but did you really want to do all of this ? If
> not, I'll revert what you don't like. Personally, I would have preferred
> you to move on to some other fun / high-impact win, rather than getting
> bogged down in random details here ;-)

Personally I would have preferred a more integrative advise like:

Please wait for the decision by the Design Team and we would be very 
glad if you could implement the resulting graphical approach by a patch.
> [...]
> >   - It adds a configuration option
> [...]
>         In my experience of user interaction - adding configuration options is
> a cowardly, and silly way to deal with disagreements about defaults :-)
> [ not your fault, the design team's issue; check out the settings dialog
> in any Apple product ].

Great experience: Everybody providing different options for different 
user groups is a coward, because he doesn't want to impose his personal 
opinion on a large usergroup whose needs he can't take into account if 
he didn't do any UX research.

Yes - it is our fault to allow different opinions.
>         IMHO we badly need to hide / remove tons of our pointless configuration
> options - which incidentally also slow down program execution, slow down
> our startup, bloat our user interface, make testing harder, and thus our
> code buggier and so on. [ At least, I'm willing to argue that in detail
> but ... ;-]

Who decides if they are pointless?
You?

Removing superfluous options is good, but this needs to take into 
account the experience of the UX experts, probably based on user studies.

Otherwise not only community members but long-standing users of our 
product will feel disregarded and turn away from LibreOffice.
>         Personally, I liked what Sebastian did originally - it was sufficiently
> better to be really nice; was there any real need to bloat the feature,
> further complicate the code, and discuss this minutia to death ? do I
> really need a green page shadow ?

Do you really need any shadow at all? You could just have four small 
lines to show the border of the document. This would be the leanest way 
to handle this topic on the code side.

But visuals are important - and perhaps these options make sense in a 
broader surrounding when the entire application background might become 
configurable...
> > I'll let design team play and discuss with that, when they agree on a
> > default, I'll provide an additional patch to take it into account.

Thank you very much for this point. There are developers who don't have 
any interest to implement something others think to be important.

I'm quite sure that the Design Team could be able to agree on one 
proposal during a few days - but due to Michaels comments like the 
following...
>         Thanks for your patience Sebastien, I'd just recommend moving onto
> something else at speed ;-)

... I will not be the one to drive any decisions in the Design Team at 
the moment.

Best regards

Bernhard