Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

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,
> sorry.

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 relationship) too.

>> and if this is the official position of the LibreOffice
>> project
> 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
both directions.
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
>      teams

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
>      community.

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 our basis.
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
javascript - I don't know if this patch would be included in the master, 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 their advises.

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
design team.
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 decision process.

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 general goals.
> 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
> effective.

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 problems.

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 the community.

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
List archive:
*** All posts to this list are publicly archived for eternity ***


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.