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 steps into their work. A developer can tell rather quickly "wow! the way your approaching this would involve major refactoring of code, I think investigating on this other way would have more chances to be implemented quickly and easily". Having steps in evolution allow to bring them more quickly to end users, thus allow to get more feedback and correct if needed. > 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. Agreed > > > > 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... Again, I don't think this was Michael intention (he was off today, I hope he won't be mad at me tomorrow for having interpreted his thoughts). > > > > 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. Again, I wasn't aware of the existence of the design list (my mistake, I should have seen it on the mailing list page). I was even surprised that there were no design comments on the bug report, only developers ones. > > > > 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@freedesktop list as "this list". > > 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. > > Once more you define "discuss" as opposite to "work". The design > list's topic is as well working as decision making. Disregarding this > team leads to the feelings you evokes not only by me... > > > Sebastien, I hear the complaints; and I read your nice > > patches (and just pushed them[1]), but did you really want to do > > all of this ? If not, I'll revert what you don't like. Personally, > > I would have preferred you to move on to some other fun / > > high-impact win, rather than getting bogged down in random details > > here ;-) > > Personally I would have preferred a more integrative advise like: > > 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. That's what I thought and that the second patch purpose, allowing non developer people to test their ideas and come back with a commonly admitted result. > > > > [...] > >> - It adds a configuration option > > [...] > > In my experience of user interaction - adding configuration > > options is a cowardly, and silly way to deal with disagreements > > about defaults :-) [ not your fault, the design team's issue; check > > out the settings dialog in any Apple product ]. > > 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. > > Yes - it is our fault to allow different opinions. > > > > IMHO we badly need to hide / remove tons of our pointless > > configuration options - which incidentally also slow down program > > execution, slow down our startup, bloat our user interface, make > > testing harder, and thus our code buggier and so on. [ At least, > > I'm willing to argue that in detail but ... ;-] > > Who decides if they are pointless? > You? > > Removing superfluous options is good, but this needs to take into > account the experience of the UX experts, probably based on user > studies. > > Otherwise not only community members but long-standing users of our > product will feel disregarded and turn away from LibreOffice. > > > > Personally, I liked what Sebastian did originally - it was > > sufficiently better to be really nice; was there any real need to > > bloat the feature, further complicate the code, and discuss this > > minutia to death ? do I really need a green page shadow ? > > Do you really need any shadow at all? You could just have four small > lines to show the border of the document. This would be the leanest > way to handle this topic on the code side. > > But visuals are important - and perhaps these options make sense in a > broader surrounding when the entire application background might > become configurable... Yes, that's where developer and UX team interaction is important: defining steps that are acceptable in terms of development and in terms of visual rendering. Working together we can find out elements that could give visual improvment without needing vast code reworking, and step by step going toward that "big picture" that the UX team would have proposed if they had worked without concertation. > > > >> I'll let design team play and discuss with that, when they agree > >> on a default, I'll provide an additional patch to take it into > >> account. > > Thank you very much for this point. There are developers who don't > have any interest to implement something others think to be important. > You're welcome. so please don't leave and play with it or this whole discussion & coding would have been in vain. > I'm quite sure that the Design Team could be able to agree on one > proposal during a few days - but due to Michaels comments like the > following... > > > > Thanks for your patience Sebastien, I'd just recommend > > moving onto something else at speed ;-) > > ... I will not be the one to drive any decisions in the Design Team > at the moment. I regret that. The two people who decided to give up had good arguments and it all seem to be a misunderstanding. I'm a new developer on libreoffice so maybe Michael feared that I leave if design team emitted objections on my patches. That's not the case. And if I didn't care about your opinion, I won't have spend a half week to implement configuration options to allow you to make your test. You opinion matters, I hope you'll change your mind and, again, I apologize if you've been hurt my some of my comments. > > Best regards > > Bernhard Regards Sébastien -- 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 ***
