Le Wed, 09 Mar 2011 22:11:19 +0100,
Bernhard Dippold <email@example.com> a écrit :
Hi Michael, all,
Reply inline :-) (don't fear scrolling even if you do not see any
answer for some time)
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 don't care about the delay of inclusion (the only fear I have is my
hard drive failing with hours of non pushed work :-) ). Discussion is a
good thing and I hope it won't be broken because of misunderstandings.
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
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.
Again, I don't think that Michael wanted to hurt anyone's feeling. I
strongly believe that LO have to take into account user feedback about
usability and design, so I'm pleased to have discussion with design
people. Interaction is a good thing.
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.
Thing is, the original bug report provided a 4 borders mockup, I
quickly implemented it (minus some display glitches that were not
fixed, they're present in stable LO version but are not this visible
since the shadow is thin and opaque), and when I show it to some people
everybody was suprised that the shadow was on 4 borders (the 5 people
who saw the screenshot told me that there should be only 2 borders).
Here this is my fault, I didn't knew that the design team had a mailing
list (which seem to take 8 hours to deliver mails into my inbox), if I
had, I would have posted the screenshot here to get more feedback. I
apologize for that and didn't thought it would go that far.
I will no longer be part of such a community.
As I said to Nick, I hope that my apologies will make you change your
mind. I have very bad taste regarding design (as a vast majority of
developers), so I fully trust design team opinion when it's given.
Michael Meeks schrieb:
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
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".
I perfectly understand and agree with that. That's why I made the
second patch (which gave me headache), I wanted that people who *know*
about design could test their feeling on real use cases rather than
trying to get something out of Gimp/Photoshop. And that's why I said
several times that he would be nice if some people from design team
could have a master build so they can test design patches even before
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
Sorry, english isn't my mothertong and critics was maybe too strong, it
had to be understood as remarks I guess…
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.
I disagree. I think having a developer may help design guys to have
steps into their work. A developer can tell rather quickly "wow! the
way your approaching this would involve major refactoring of code, I
think investigating on this other way would have more chances to be
implemented quickly and easily". Having steps in evolution allow to
bring them more quickly to end users, thus allow to get more feedback
and correct if needed.
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
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
Again, I don't think this was Michael intention (he was off today, I
hope he won't be mad at me tomorrow for having interpreted his
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
Again, I wasn't aware of the existence of the design list (my mistake,
I should have seen it on the mailing list page). I was even surprised
that there were no design comments on the bug report, only developers
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), 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
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
That's what I thought and that the second patch purpose, allowing non
developer people to test their ideas and come back with a commonly
- 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
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
Yes, that's where developer and UX team interaction is important:
defining steps that are acceptable in terms of development and in terms
of visual rendering. Working together we can find out elements that
could give visual improvment without needing vast code reworking, and
step by step going toward that "big picture" that the UX team would
have proposed if they had worked without concertation.
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
Thank you very much for this point. There are developers who don't
have any interest to implement something others think to be important.
You're welcome. so please don't leave and play with it or this whole
discussion & coding would have been in vain.
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 the moment.
I regret that. The two people who decided to give up had good arguments
and it all seem to be a misunderstanding.
I'm a new developer on libreoffice so maybe Michael feared that I leave
if design team emitted objections on my patches. That's not the case.
And if I didn't care about your opinion, I won't have spend a half week
to implement configuration options to allow you to make your test.
You opinion matters, I hope you'll change your mind and, again, I
apologize if you've been hurt my some of my comments.
Unsubscribe instructions: E-mail to firstname.lastname@example.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
[libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout · Bjoern Michaelsen
Re: [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...) · Bernhard Dippold
- Re: [libreoffice-design] Re: More general stuff - Please no ribbons/tabs! (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy