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!

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!

Context


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.