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

Hi Michael, all,

sorry - this mail is really long!

Please scroll to the bottom 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.
> Hopefully then everyone is friendly to each other, and tries to be
> both winsome and persuade each other of the merits of their position.
> Of course - too much persuading will also waste coders' time
> bogging them down in endless E-mail, that also squanders scarce
> resources - so ... in some sense it is hard to win :-)

Don't look only on the coder's time - other community members spend 
their time too.
> Perhaps it isn't good to have coders on a high-volume
> argue-to-and-fro list; perhaps they just want the conclusions. But
> they will also want concrete conclusions fairly fast.

I don't think that we need long discussions on each and every topic -
for modifications changing the general visual impression this might take 
a bit longer.
> > But at least at the moment, where we are a young group working
> > on  our basic structures, this takes some days...

And when we established our team, defined our visual goals and general 
branding language, this will become faster too.

Sébastien's problem was that he couldn't know that our proposals have 
been part of our internal decision finding process and not different 
work orders to be implemented by him.

Here we need to be more precise.
> Sure sure, conflict is all part of life :-) so - I'm sorry we have
> a small one today; but - in the end I think it will lead to a
> better understanding, and I hope, friendship.

I'm open for both :-)
> > And I hope you don't mean it this way, but it sounds like
> > this:
>
> Ah - this is not what I mean:
>
> > 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...
> Of course I think we need to care about the design team's advice
> and give lots of weight to it - so I don't want to say that, sorry
> if that is what you hear.
>
> > I don't read your mail as encouragement to them :-(
>
> Sure - but this is because (in this instance) they (to my mind)
> burned a big chunk of a new developers' time and motivation - and
> made the product worse because of it.  [...]

If these options would have been designed to be implemented in the final 
LibreOffice some day, I'd agree. But I didn't read Sébastien's mail this 
way.

> > 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.
>
> Yes - perhaps we should have another freedesktop list for this sort
> of thing, so we can include coders in discussions easily.

Please don't use more freedesktop lists for community communication.

If really necessary, we can have our own libreoffice.org lists - and the 
majority of their users feel comfortable to keep discussions on the 
lists without the need to include all the participants in their replies.

Even if you feel different, I don't need any of the double mails I 
receive when one of my postings to the dev list has been replied by 
anybody else.
> It seems we have the same problem with each other's lists: too
> much talking, and hard to filter the gold from the dross in each
> place. Would you support a new list for those interactions ?

No - it's not "too much talking". There are just some topics not related 
to my personal interest.

Even if I skip most of them by just reading the subject, this gives me 
more knowledge on what is done over there.

What I'd like to see are more [TAG] marks like you do for [PATCH] or 
[REVIEW].

On both lists we could have an [UI] or [UX] tag for topics relevant to 
this area.

But with regards to new lists at all, we discussed this topic already 
for a dedicated QA list: Interaction of the different teams and 
knowledge about their tasks is more important than skipping unrelated 
postings. I think this is true for our topic too.

> > 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.
>
> Again - the code was merged day #1, then these 'fixes' were merged
> week #2, and we are not blocking on the advice of the design team.
> Clearly if something -really- upsets them we will back out the
> changes. Clearly if -everything- upsets the design team, and we
> find ourselves in some constant conflict - the design team's crying
> will start to become normal background noise, and have rather less
> impact. That is how relationships work right ?

Not really:

*If* the design team would be upset by any UI related development, it 
would be worthwhile to find out the reason for such feelings.

Just skipping them as "normal background noise" is far too easy and 
indicates an attitude of ignorance for the broader community: This is 
exactly what I called "two classes"...

> > 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.
> So - I am not a UI designer :-) [...]  Most of the UI designer
> talks I've been to (and there have been many) made fun of the many,
> ridiculous settings in various config dialogs, and as a coder I've
> seen how the intersection of many different options can make the
> user interface very confusing and non-intuitive, as well as the
> code more buggy. But of course, we can go too far removing them
> :-)

That's a topic that really needs interaction and decision making 
*before* someone starts coding IMHO.

Removing unnecessary options is very reasonable in my opinion, but some 
are crucial for user groups the developer doesn't think of.
> > [...]
>
> You really think we need to add more options in general ? Lots of
> the existing options are simply cowardly cop-outs; I open my
> tools->options and see the Memory settings: eg. the "Graphics
> Cache" settings are (I would argue) totally meaningless to 99% of
> end users, and dangerous to all the others :-) If they have to even
> see them: we failed already IMHO. Yet this kind of option tends to
> breed in the wild ;-) sadly because often, it is simpler to add
> such a thing to the UI, than think hard and do it right.

Fully agreed. Such options should be implemented in the code without 
user interaction.

The example you mentions has been the only way for me to use 
OpenOffice.org for my dissertation: With more than 40 large images 
working wasn't possible without adjusting this memory setting...
> Perhaps in this case yet-another option is needed just for
> consistency, that is an argument I might buy *but* if we use a
> consistency argument, then, IMHO, *first* we need to get all apps
> rendering the same pretty page outlines - since that is a -far- more
> noticable consistency problem (right?), so we mis-prioritised here.

No question - the document shadow doesn't need to be modified by the 
user, but it should be consistent with the general visual language of 
the product (and of the OS/distribution if possible).

But what I understand of this discussion is far broader than the shadow 
question.
> > Who decides if they are pointless? You?
[... "they" are pointless configuration options, to be hidden/removed by 
"us"...]
> Some discussion with the design team I would have thought.

Discussion and common agreement - in an early stage of development to 
avoid negative feelings when coding has gone in a wrong direction and 
needs to be reverted.
> [...]
>
> Anyhow - that is my very long rambling E-mail, that consumed an
> hour+ to write, and no doubt some hours to read;

... and writing on my side much more time ...

> I hope we can
> hammer this meta-issue through in linear time - and that it is all
> worth it in the end.

+1

> My conclusions are:
>
> * this is just my opinion
> * I value your input a lot
> * on this specific point:
>   + I think this was the wrong decision personally
>   + I'm fairly sure the interaction was sub-optimal and needs fixing:
>     perhaps by a new list
> * I want the design team to succeed and be effective
>   + my advice should be read as trying to help achieve that
> So; hopefully that helps ?

Yes - it shows that you wanted to reach something different than what 
you expressed in not only my personal opinion.

> it is not some personal attack on
> designers and their usefulness.
I know that.

But I'm sorry to say, that we still seem to lack in consensus about 
single developer's positions with regards to general goals of the 
community, vocalized by their experts in the respective areas.

I think the only way to solve this point is by believing in other 
community member's expertize and taking it into account not only as easy 
to be ignored personal opinion, but as a general guideline in an area 
our personal opinion is not based on the same expertise.

I still believe that this needs discussion and conviction.

While this doesn't mean to hinder contributors from providing their 
work, it is neither a reason to disqualify discussions leading to 
consensus and decisions as "long stream of complaints", allowing the 
contributors to ignore it, just because "they don't see it as useful input".

Every community member - coder or not - has to know that the LibreOffice 
community has general goals and dedicated ways to achieve them. If other 
ways don't interfere with the way the community wants to go, nobody will 
be hindered to contribute in their personal way (while in most cases 
people like to spend their time more efficiently using the established 
workflow when they've been told about it).

Only if the contribution means that the generally agreed way to work is 
influenced negatively, the contributor is asked to modify it.

As long as the contributor is open to positive feedback, this doesn't 
mean to put him down or to disregard the contribution: the next 
iteration will be valuable for the contributor and the community.

So in a short term:

* Every community member deserves the same respect for his contribution.

* No contributor should be hindered to contribute in a way that brings 
LibreOffice forward.

* No contributor should be told that his opinion is more valid than the 
recommendations of experts in their dedicated fields (but she is free to 
convince them).

* If the contribution might interfere with general community goals or 
agreed ways to reach these goals it might be handled like code 
introducing bugs in other areas of the product. This will probably lead 
to modification of the contribution - in very seldom cases to rejection.

Best regards

Bernhard

PS: Just to state it again: This is not at all related to Sébastien's 
patch and the way he interacts with the Design Team - He is just great!