[Libreoffice] [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...)

[Michael Meeks]

Hi Bernhard,

On Wed, 2011-03-09 at 22:11 +0100, Bernhard Dippold wrote:
> At first I want to thank Sébastien not only for his work, but also for 
> being open to the discussion here, even if this means to delay the final 
> inclusion of his patch.

	Agreed - we all think Sebastien rocks ;-) That we can agree on first,
and this debate is not in fact about him - he acted in an exemplary
manner (so I dropped the CC).

	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.

	Having said that, I do think there might be some difference of
understanding here, so lets dive into more detail.

	Also, apologies for not reading the mail - I spent yesterday heads
down, doing many hours of tedious, mostly mindless merging work - the
kind of stuff that makes programmers feel like donkeys involving no
interesting, creative decisions at all ;-) It is an intricate, painful,
mind-blowingly tedious task - but someone has to do it :-) Anyhow ...

> 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 :-)

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

	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.
		+ if I go adding garish / new icons to a theme, I
		  expect to get beaten up by you guys - this is yours,
		  all yours :-)

* 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 ;-)
		+ defaults can have a huge impact on performance,
		  maintenance, complexity and code flow
		+ changes to dialog layout & behaviour require
		  coding support - which -must- be -persuaded- not
		  dictated

* weak ownership
	+ "lets re-architect the whole user interface"
		+ the weakness here is mostly one of coding resource,
		  and impact on architecture
		+ it is simply not possible or practicle to dictate
		  terms to other teams
	+ rejecting inclusion of working improvements
		+ this has an incredibly negative impact on the growth
		  and fun of the coding community. ie. Sebastian's work
		  was merged before getting UI review, this I expect to
		  continue.

	So - I suspect the arguments here are around the 'middle' and 'weak'
categories, what belongs where and what happens in what order etc.

	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.

> 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 :-)

	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.

	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" :-)

	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. 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 :-)

	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.

	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.

	Obviously - hacking on improving the UI -must- be a fun task, otherwise
you'll not get any coders to do it. 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.

	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.

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

	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 :-)

	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.

> But at least at the moment, where we are a young group working on our 
> basic structures, this takes some days...

	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.

> 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. Why worse ? the configuration feature is
not terrible in itself - is it really worse ? Well, yes of course
because this replaces other work that would have been far more useful in
this zero sum game.

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

	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 ?

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

> 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 :-) but the anti-gratuitous option
group-think is fairly well entrenched in GNOME; it also seems to explain
a lot of the Netscape Foo -> Firefox transition, and it also seems to
underly Ubuntu's Unity, and many of the more successful software
projects I've seen. 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 :-)

> Yes - it is our fault to allow different opinions.

	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.

	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.

> Who decides if they are pointless? You?

	Some discussion with the design team I would have thought.

> Removing superfluous options is good, but this needs to take into 
> account the experience of the UX experts, probably based on user studies.

	Of course.

	Anyhow - that is my very long rambling E-mail, that consumed an hour+
to write, and no doubt some hours to read; I hope we can hammer this
meta-issue through in linear time - and that it is all worth it in the
end.

	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 ? it is not some personal attack on designers
and their usefulness.

	All the best,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot