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 law, and their
Re: [Libreoffice] [libreoffice-design] General relationship between coders and designers (was: [PUSHED]fdo#31251...)
Le Wed, 09 Mar 2011 22:11:19 +0100, Bernhard Dippold bernh...@familie-dippold.at a écrit : Hi Michael, all, Hi, Reply inline :-) (don't fear scrolling even if you do not see any answer for some time) 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. 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. Again, I don't think that Michael wanted to hurt anyone's feeling. I strongly believe that LO have to take into account user feedback about usability and design, so I'm pleased to have discussion with design people. Interaction is a good thing. 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. 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. *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. I perfectly understand and agree with that. That's why I made the second patch (which gave me headache), I wanted that people who *know* about design could test their feeling on real use cases rather than trying to get something out of Gimp/Photoshop. And that's why I said several times that he would be nice if some people from design team could have a master build so they can test design patches even before they're included. 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. Sorry, english isn't my mothertong and critics was maybe too strong, it had to be understood as remarks I guess… 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. I disagree. I think having a developer may help design guys to have
