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