[Libreoffice] [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...)
bernhard at familie-dippold.at
Wed Mar 9 13:11:19 PST 2011
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
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.
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
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
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
> 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 at 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), 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?
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
>> 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
> 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
More information about the LibreOffice