Re: [libreoffice-design] General relationship between coders and designers

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
community:
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 design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***