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

... second part ...

Please scroll to the bottom of the this mail to find a short conclusion.

> 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!

--
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 ***