Re: [libreoffice-design] General relationship between coders and designers
Hi Bernhard, On Tue, 15 Mar 2011 00:11:48 +0100 Bernhard Dippold wrote: > >> 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"... No, that is not an "attitude of ignorance for the broader community" and no "two classes" issue. If introduce a pink button in LibreOffice and get flamed for it by any single person (coder or noncoder) a few minutes later because he would prefer it in bright green, I would likely ignore it (speaking of master, not a release branch obviously). Otherwise I would not be making any progress at all or just be changing the same colors over and over again. If I get a link to a discussion on a mailing list a week later showing consensus of the design team that bright green is indeed better than pink in this case, I would change that. And I would expect the design team to defend that decision and keep the discussion away from me from that point on (that includes links to the discussion in the relevant places). Would I take the word of a trusted UXer without waiting a week? I might, esp. if I get the feeling that I will end up changing the stuff anyway or if there is a deadline (like a release branchoff) looming. This is a lot different for most implementation issues, as consensus there is often immediate. But this has to do with the topic and not with "classes". > That's a topic that really needs interaction and decision making > *before* someone starts coding IMHO. In most cases not. Most design choices are easily changed and tweaked afterwards, but the hard part is enabling them to be tweakable at all. Starting on the code will also show you what is easy to do and what is hard -- an information you can only afford the luxury to ignore, if you have unlimited resources. > 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". As long as there is no consensus, a coder can not derive _any_ valid action from the discussion, so the only reasonable action is to ignore it for his coding decisions. Any objections to that conclusion? He might prepare his coding for likely outcomes, but that is guesswork. He might also take part in the discussion, but that is independent from his coding work (modulo his expertise on what is doable). > 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. I agree mostly. However "experts in their dedicated field" is rather vague and can be misused easily regardless of the "field" being coding or UX. I would much prefer "community consensus", which -- while being equally vague -- at least does not introduce the exact "two classes" (experts/nonexperts) issue described above. Best Regards, Bjoern -- https://launchpad.net/~bjoern-michaelsen -- 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 ***
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 h
Re: [libreoffice-design] General relationship between coders and designers
Hi Michael, all, sorry - this mail is really long - and with a size of 29 kB rejected by the mail server! So I had to cut it in two parts. Please scroll to the bottom of the other mail 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
Re: [libreoffice-design] General relationship between coders and designers
Hi Michael, all I started to reply yesterday already, but this will take some time. I just wanted to let you know that I appreciate very much the way you describe your thoughts and intentions in this mail. Michael Meeks schrieb: [...] 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. I never thought of personal attacks, it has just been my concern about different perception and appreciation for different community member's contributions. I'll describe my position in a (lengthier) reply - hopefully leading to something we all can agree to and store at the wiki as reference for future interaction. For the moment I just want to let you know: Thanks for your time and effort to work on this topic! Such interaction is necessary to keep good work going on. Based on mutual respect and understanding I'm more than willing to continue my contributions and hope that everybody else feeling sad about this topic might get a more positive impression of our community too. Best regards Bernhard -- 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 ***
Re: [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...)
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
Re: [libreoffice-design] Re:[libreoffice-design] General relationship between coders and designers
Hi all, On 3/11/2011 1:36 AM, Bernhard Dippold wrote: As I said to Nick, I hope that my apologies will make you change your mind. I have very bad taste regarding design (as a vast majority of developers), so I fully trust design team opinion when it's given. You don't need to apology for anything! Very true. Just to clarify with yourself (Sebastien) and Christoph, there's no need for either of you to apologise. Sebastien you're doing a great job and I'm sorry you got caught up in this at all. I'm more disappointed with Michael's "down get bogged down by Designers" mentality than anything, but even on his part, I can see this is just a misunderstanding, one which is probably the result of his not having time to read the thread, but the assumptions made were quite typical of developers who don't think much of Designers. Like Bernhard said, it's just demeaning for that to come from one of the most prominent developers in the community. If your opinion would have been shared by Michael, I'd never had written such a mail. [ skipping more comments I totally agree with ...] Thanks for your patience and positive attitude towards other parts of the community. +1 I still hope that this is the way we all can work together on topics important to more than one single group or team. Best regards Bernhard While I'm going to stick to my guns and avoid this issue so I can focus more on a more straight-forward current Design topic, I'm sure someone else with step in. We have a great crew and I hope this hasn't diminished your resolve to work with them Sebastien, thanks for being so patient. I've worked with Developers who respect Designers and vice versa, and the result of that collaboration is always magic. -Nik -- 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 ***
[libreoffice-design] Re:[libreoffice-design] General relationship between coders and designers
Hi Sébastien, all, Sébastien wrote: > Le Wed, 09 Mar 2011 22:11:19 +0100, > Bernhard Dippold a écrit : > > > Hi Michael, all, > > Hi, > > Reply inline :-) (don't fear scrolling even if you do not see any > answer for some time) I'll remove the parts I don't reply to ... > > > > > 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. > > I don't care about the delay of inclusion (the only fear I have is my > hard drive failing with hours of non pushed work :-) ). Discussion is a > good thing and I hope it won't be broken because of misunderstandings. +1 > > > [...] > > > > *Short version:* > > If Michael (as one of the most relevant developer in our community) > > is right with attitude against non-coding contributors and if this is > > the official position of the LibreOffice project and The Document > > Foundation, I will not keep on spending my spare time and dedication > > to this open source project any more. > > Again, I don't think that Michael wanted to hurt anyone's feeling. > He probably doesn't do this on purpose, but there are two important points that need consideration: 1. He is one of the main developers in LibreOffice, part of the SC. So his opinion has more weight in our community than posting by most of the other developers. 2. He repeatedly suggests to include the patch irrespective to the result of our discussion - and to leave this topic afterwards, so any proposed modification will not be implemented if you would follow his suggestion. I still hope that this is *not* the official position of the Steering Committee and the LibreOffice community. > > > > > 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 where the > > broader community is not involved in decisions taken by non-experts > > but influencing the entire community and it's public standing. > > Thing is, the original bug report provided a 4 borders mockup, I > quickly implemented it (minus some display glitches that were not > fixed, they're present in stable LO version but are not this visible > since the shadow is thin and opaque), and when I show it to some people > everybody was suprised that the shadow was on 4 borders (the 5 people > who saw the screenshot told me that there should be only 2 borders). > Here this is my fault, I didn't knew that the design team had a mailing > list (which seem to take 8 hours to deliver mails into my inbox), if I > had, I would have posted the screenshot here to get more feedback. I > apologize for that and didn't thought it would go that far. > It's not your fault at all. Without Michaels recommendations this topic would have stayed as minor as it should be. But I think it shows quite well what can happen, if we don't work together on topics relevant to more LibreOffice teams than just the developers. We need to establish a workflow that allows easy coding as well as early inclusion of other teams relevant it this specific case. But at first I have to know about the overall relationship between developers and non-coders. In OpenOffice.org the ESC decided to modify the MimeType icons towards the colorless ODF icons. They didn't include UX and Marketing, blocked alternative proposals and caused lots of work leading to nothing. I know that part of the problem has been based on Sun/Oracle vs. volunteer community, but the other part is about non-coders' dependency on developer to get their ideas implemented or to have their expert concerns respected. I'm sorry that this topic changed to one of the most general questions in a community including developers and other community members. I should have started a new thread to make it clear, that your patch has just been the trigger, not the reason for my complaint. > > > > I will no longer be part of such a community. > > As I said to Nick, I hope that my apologies will make you change your > mind. I have very bad taste regarding design (as a vast majority of > developers), so I fully trust design team opinion when it's given. You don't need to apology for anything! If your opinion would have been shared by Michael, I'd never had written such a mail. [ skipping more comments I totally agree with ...] Thanks for your patience and positive attitude towards other parts of the community. I still hope that this is the way we all can work together on topics important to more than one single group or team. Best regards Bernhard -- 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 ***
Re: [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...)
Hi Michael, all, 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. I tried to calm down for more than one day by now, but as Michael repeated his position, I have to reply now. Sorry for not being able to react as positive as Christoph - perhaps I didn't spend enough time in UX/UI to learn to live with this kind of disappointment. *Short version:* If Michael (as one of the most relevant developer in our community) is right with attitude against non-coding contributors and if this is the official position of the LibreOffice project and The Document Foundation, I will not keep on spending my spare time and dedication to this open source project any more. 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 where the broader community is not involved in decisions taken by non-experts but influencing the entire community and it's public standing. I will no longer be part of such a community. *Long version:* Michael Meeks schrieb: Hi Sebastien, On Tue, 2011-03-08 at 09:09 +0100, Sébastien Le Ray wrote: this simple shadow patch has generated a long discussion on Libreoffice-design. Some people don't like the color, some people don't like the amount of blur, some people want no shadow at all, some people want a "4 borders" shadow. You're right about the different personal feelings, but they are not a decision of the LibreOffice Design Team. For a developer interested in working on a certain topic it would be easier to get a final voting like "The Design Team asks you to add a 8 px wide blurred shadow in grey transparency to all borders of the document. If the zoom factor reduces the space between two sheets to less than 16px, the overlapping areas of the shadow should be cut off. This should apply to every area of LibreOffice, where document borders are visible, namely Writer, Impress, Draw, XML forms [others not yet searched for]." But such a specification is necessarily a result of some kind of discussion, if there is no single decision maker. As we don't want such single person decisions, this list is "talkative". So here is a second patchset that tries to address the first three critics : I hope you understand now, that the comments have not been meant as critics, but as part of the decision making process in the Design Team. Perhaps we need a different way to interact with developers, keeping them out of our processes and coming back to them with the results. This could be the relevant bug-report, a mail on the developer list or any other structure. But at least at the moment, where we are a young group working on our basic structures, this takes some days... In my eyes it is very important to show developers how the Design Team works, giving them background information on important UI and UX points. So - firstly, this -sounds- like an interaction disaster :-) I hope it is not of course, but it looks like this: We finally get a competant, enthusiastic, motivated developer - actually fixing our horrible user interface problems: and he does some great improvement - and our design guys apparently emit a long stream of complaining left and right ! That, if true, is hard to excuse. And I hope you don't mean it this way, but it sounds like this: A team of individuals works hard to establish a common visual design for LibreOffice. They spend hours and days of hard work on this topic and their work seems to be respected by the community. 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... We need to greet new guys with a torrent of encouragement instead I think. Right - but these new guys are not only developers, but other community members like designers and UX experts too. I don't read your mail as encouragement to them :-( I hope I'm wrong - I don't read the design list because I can't interact there [ Reply-To: mangling sucks ;-] That's your personal opinion - everybody else can subscribe to the list and avoids offlist communication and duplicated mails... - but this paragraph smells problematic. I think we need to remember that the perfect is the sworn enemy of the good - so lets get good across the code, before we get perfect. Of course this statement is right - but working on a topic without respect to the specialists is even worse than trying to be as good as possible. Perhaps we should move all programmer interaction on design / UI topics onto this list, or a new Freedesktop one - and leave the 'design' list as more of a 'discuss' type forum. You refer to the libreoffice@freed
