Hi Michael, all,
sorry - this mail is really long - and with a size of 29 kB rejected by
the mail server!
So I had to cut it in two parts.
Please scroll to the bottom of the other mail to find a short conclusion.
Michael Meeks wrote:
> Hi Bernhard,
> On Wed, 2011-03-09 at 22:11 +0100, Bernhard Dippold wrote:
> Firstly, I of course want to apologise that my mail made you mad -
> clearly I was trying to redress an imbalance I was concerned might
> exist, and over-emphasised one side to try to help re-balance
> things. Unfortunately, that tipped the balance completely the other
> way - which I can understand (in retrospect) sounds upsetting,
Thanks for your understanding!
I know that we both want the best for our community - but as our point
of view is different, we probably will always have different preferences
and ways to work.
> Having said that, I do think there might be some difference of
> understanding here, so lets dive into more detail.
I know that this is not your normal way to communicate, because you
prefer direct action and less discussion. So I want to thank you for the
time you spend here.
> Also, apologies for not reading the mail [...]
You read it and replied to it (and this in a reasonable time - while
time can't be valued by anybody than oneself): No need at all for any
apology. If you replied to it without reading.... ;-)
>> If Michael (as one of the most relevant developer in our
>> community) is right with attitude against non-coding contributors
> I hope I'm not against anything, particularly not designer
> developers :-) I am -for- encouraging coders to get their code into
> the product, and for designers to get their ideas realised *and*
> simultaneously to create a fun place for everyone to work together,
> with good relationships. Of course that seems to have gone wrong
> here, and needs fixing :-)
You stated clearly that you are against any delay of development - so we
need to find a way to include the other points you mentions (especially
the "fun" factor for developers and non-coders and the good
>> and if this is the official position of the LibreOffice
> So - of course, my view is not an official position. Having said
> that, it is perhaps worth discussing.
We both know that it is not very likely so see a position paper by the
SC that doesn't cover your points in the area of coding. But it might
avoid this kind of misunderstandings in future, if there would be such
an official position all teams can agree to.
> In the sphere of design, I see the design team as having a whole
> spectum of responsibility. At one end - one similar to the coder's
> and at the other a critical advisory and leadership role. So -
> starting at the coder-like end:
> * hard ownership role: + I expect the design team to own all of the
> artwork, icon themes, etc. in the product.
This is one part of the visual design, where we want to achieve a better
consistency between product, website and marketing.
Even this needs coding support - as designer can't implement their work
on their own. But it might be easier to convince some developers to
support such an implementation.
> * middler-ground role + defaults / dialog layout etc. + clearly
> this is fuzzier: dialog layout is (currently) dependent on l10n, so
> some things can't be done: we can't wedge 10x buttons into a small
> space ;-)
No problem at all: As this has to be taken into account by UX this is
one of the points we consider from the start.
> + defaults can have a huge impact on performance, maintenance,
> complexity and code flow
Here we need developer input - best in an early stage of our workflow.
> + changes to dialog layout & behaviour require coding support -
> which -must- be -persuaded- not dictated
You know that I don't like the "dictatorship" description. It works in
But this is the main question in the developer - non-developer relationship.
I'll come back to this point later on.
> * weak ownership
> + "lets re-architect the whole user interface"
> + the weakness here is mostly one of coding resource, and impact
> on architecture
If these are the main arguments against a consistent UI improvement,
let's move this part up to the "hard ownership": It is crucial for
LibreOffice as product and community to define a user interface that
pleases neither the coders nor any other community members, but our
present and future users.
> + it is simply not possible or practicle to dictate terms to other
Same as above: see my opinion below.
> + rejecting inclusion of working improvements + this has an
> incredibly negative impact on the growth and fun of the coding
That's what I see too and want to avoid by having established some rules
to understand and follow.
"Improvement" can be seen very differently - for working improvements
where all related teams can agree on this term I don't see a reason to
reject any contribution.
But designers can't create any artwork they want to and declare it as
official LibreOffice artwork just because they and perhaps two or three
others like it better than the branding and design the community uses as
It is important to keep our public recognition in our mind.
Even if I'm not a coder, I try to use an example from your part of the
If a coder would add a marvelous feature for Mac only based on
even if some people would like it.
You can see graphical inconsistency and UI modification with negative
impact on usability and user experience as design related bug. You will
not care about it very much, if this bug is not serious and is likely to
be worked on later on and the positive effects of the patch value higher
than the negative ones.
But in certain cases (patch breaks some important feature in another
part of the code, not following general coding conventions, leading away
from the overall goal...) it is necessary to modify the patch before it
is included in the master. This can be done by the contributor, the
reviewer or anybody else - and it works best, if the contributor can be
convinced that the modification is positive and necessary.
While this procedure is quite easy to understand inside the developer's
world, it is quite the same in other areas (I think of UX and visual
design as well as marketing) too. But as the experts can't improve the
code themselves, they need to *convince* either the contributor or any
other developer to do the modifications.
If there have been general guidelines already established, it is easy to
point to them (or even better to tell the contributor beforehand about
them), otherwise discussion will take more room.
> ie. Sebastian's work was merged before getting UI review, this I
> expect to continue.
Sébastien's patch causes minor inconsistencies (different shadows on
different documents), it might have been influenced by a UI guideline on
light positioning and shadow color/intensity (but we haven't such a
guideline at the moment), so it might be an example of different opinions.
As I believe that Sébastien is willing to keep on working on this topic
I fully support the merging in this special case, but in other cases
there might be conflict potential we should address beforehand.
Removing already integrated work from the master might cause even more
negative feelings than advising to follow certain rules...
... but it might have the same negative effects to tell the experts
that their expertise is worth nothing, because the developer who
provided the patch should not be discouraged to keep on working for
LibreOffice in his/her way.
> So - I suspect the arguments here are around the 'middle' and
> 'weak' categories, what belongs where and what happens in what
> order etc.
You define UX as "weak category". This is merely wrong in my opinion.
Neither I nor you are in a position to *know* what our users want and need.
That's why we need UX experts and user surveys if we want LibreOffice to
increase it's market share by contented people. And we need to follow
That's the same with marketing experts for public recognition: Their
expertise has influence on other teams (including developers) as well.
> Personally, I don't have a defined view of how that works. In
> everything that I'm involved in I prefer informal, relational
> process. This means that "power" such as a "veto power" and the
> like simply don't exist :-) If designers feel -extremely- strongly
> that something shouldn't go in - I'd want to listen very carefully
> since you contribute so much; but if the relevant developer feels
> similarly strongly, then we'd have a problem and need to dig more
> (and so it goes on). I don't think hard and fast rules capture the
> real world in an incredibly helpful way in these situations.
I hope very strong that we will never experience such a situation.
Most developers will be interested in feedback on their work and try to
follow expert's advises. But this means that they need to get this
feedback early to avoid double and possibly mis-oriented work.
And this means an improved and more integrated workflow on UI related work.
>> 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
> I don't think there is a two-class community, I think there are
> tons of people with different domain expertise - and that we should
> listen carefully to each of them and come up with a balanced solution
> that pleases as many people as possible: l10n, coders, designers,
> etc. I also don't believe that all developers by definition have no
> design sense and insight :-)
But that's the point: Different designers have different opinions - as
different coders prefer different tools and languages. I don't know if
it's reasonable to include a patch in Fortran with Russian comments -
but breaking the design language by adding an orange information window
(because the designer likes Orange most) might lead to more than just
frustration by the people trying to improve our design.
It can cause issues for color blind people, leading in extremitas to a
situation where LibreOffice will not be supported by a government
because it doesn't fulfill their accessibility rules...
Okay - I'm exaggerating ;-) But I think you understand the direction.
> I -do-not- see the design team having an "ultimate say" in this
> world, where their word is law, and their votes are completely
> binding :-) That is ultimately not going to work, since no matter
> what is voted - you guys need someone to implement it.
You talk about the UI if you refer to "this world"?
There is no reason for any UX/UI interested developer not to join the
Just the opposite: We're open to everybody and every opinion - and
having coders among our team is a great pleasure!
We don't want to have a final word on each and every tiny modification,
but if experts have any value in an open source community, their valid
comments have to be heard by the decision makers.
In general this is not a problem at all, when the goals are communicated
in an open way and shared by all the relevant people.
> So - at root, if you consider that I might be on your side (really
> I am) :-) and actually care about our user interface too (which I
> do), and am excited about improving it (which I am) - then
> re-reading my advice perhaps it sounds different. More like "how to
> get what you want" rather than "you must not get what you want"
More "how to understand what the LibreOffice community wants" than "how
to force everybody else to follow my way because I think it is the best".
> What I am -trying- to get across, is that if designers want their
> ideas realised, they need to deal with the people that implement them
> in a way that both encourages them, and makes good use of their scarce
> developer time.
But the other way round it's true too: If developer wants their design
ideas to become realized, it is not sufficient to just implement them if
they don't fit in the general community goals.
If they fail to convince the community - and in this case the community
experts are in the Design Team - that their work is an improvement, this
will lead to disharmony and negative reactions either on the design
(when the patch is implemented nevertheless) or on the developer side
(when it has to become modified or reverted).
So interaction and persuasion are important - and existing guidelines
are helpful in such a case too.
> This would include eg. not wasting half a week of
> their time to add random, almost-never-to-be-used configuration
> options, while the rest of the apps stick with old-style borders
If I understood Sébastien right, his intention was to provide the design
team with a working tool to decide about the shadow point on a live
system instead of just screenshots.
We both know that he had not been asked to do such work by anybody from
the design team, even if it is great that he wanted to help us in our
That's rather a communication than a developer/designer problem and they
do happen every now and then. People are independent in the way they
contribute - neither I nor you can force anybody except ourselves to
work on a topic we consider to be more important than others.
> To try to get that point home - I perhaps over-stress my
> assertion, that I don't want coders to think that they -have-to- do
> exactly what they are told by any random person on the design list,
> and I assume you would agree here.
But they -have-to- follow the general goals of the community, like
anybody else here.
One last example:
If a developer or a developer team spends weeks and months to work on a
new UI on their own implementing the existing "MS ribbons" in
LibreOffice and present the final set of patches to the community, I
don't think that their work will become implemented without modification.
This would have far too much negative impact on our users and our
> I see the UI design process as one of good, persuasive advice,
> backed by clearly communicated evidence *and* (far more importantly
> to my mind) the training of developers to make good user experience
> and esthetic decision without explicitly asking ever time.
I don't think that designers and UX experts feel as trainers only.
It is more than just a recommendation to involve any developer
interested in UI design work in the design team. In most cased smaller
modifications will just improve the present situation, but sometimes
(especially with larger changes) we need to work on the concept beforehand.
> Obviously - hacking on improving the UI -must- be a fun task,
> otherwise you'll not get any coders to do it.
Working with the design team -is- fun! Please invite every UI hacker to
try it out: They will feel very comfortable here!
> I don't want coders
> starting in that domain to get deluged with requests / have their work
> over-criticised / and/or feel un-appreciated. I am sure you don't
> want that either.
Of course I don't want them to feel this way.
That's the reason to invite them already from the beginning. Integrating
their ideas in the general UI goals is easy in the most cases.
It is fun to find the best solution together and to avoid unnecessary
efforts in any wrong direction.
> So - this underlies my recommendations; it is not an attempt to
> de-value your (valuable) work; but to try to make it rather more
Not only the designer work - the developer work would become more
effective in this way too.
>> Perhaps we need a different way to interact with developers,
>> keeping them out of our processes and coming back to them with
>> the results.
> Possibly; actually I think it is fine to have developers involved
> with that process *but* I think it is helpful for them to know that
> they do not -have-to- act on it, if they don't see it as useful
> input. I think it is also helpful for designers to know that too.
I too prefer very much to interact with UI interested developers
directly, their contributions in design are valuable and help us to find
the best way between optimal design and possible coding / implementation
But if a single developer wants to implement a feature, a UI element or
something else with a high negative impact on User Experience, our
branding, accessibility or marketing, he will be told about these
problems not only by the relevant experts, but by his/her co-developers
too, that this patch might not be the best to implement.
A developer should *not* have the right to take the community's advise
(presented by the known community experts in this very field) as just a
hint he can ignore because he is the one with the power to implement it
in the source.
And in my eyes it is one of the most central duties of the leading
people to help our new contributors on their way *in* our community. New
contributors can't know about our general goals - especially if they
have not been written down in detail, but established in consent among
This needs time and dedication - time everybody of us can use
differently - but in the end it pays back hundred times, when it leads
to new contributors understanding our community and aiming at the same
goals as we do.
... rest of the mail follows ...
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 ***
- Re: [libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout (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