Hi Michel, On Thu, 2013-04-11 at 01:10 +0200, Michel Renon wrote: > I inform you that I wrote a list of 9 articles about LibreOffice, > specially about the design process. The first starts here : > http://mr-consultant.net/blog/2013/04/thoughts-about-design-process-part-1-the-context/
Some interesting thoughts there some sensible, some completely extraordinary :-) So - in general, I'd like to ignore for now all those suggestions that revolve around telling other people: volunteers, busy professionals supporting users, etc. what to do: they seem doomed to failure. Some examples: "TDF could define some priority tasks : developers should work on nothing but those tasks ... it seems difficult to say that to volunteer developers, but TDF should really find a way to do that" In which case - here are my priority tasks for you to do as a volunteer, I hope you will do them in time for the deadline I'm about to set you of next week ? ;-> + show leadership in the UX community by contributing prolifically + eg. as an example we still have an open request (last I looked) for a design: cf. the "ESC minutes" " need design for copying styles between templates (Astron/UX) + either in that dialog or a new dialog + also issue with only editing templates that are in the mgr" This is a proposal with resources backing it and waiting to implement and interact with you on that design. I fail to understand what stops those with fire in their belly around improving the UX from actually getting involved and working on that :-) [ perhaps it's been handled already on the list but if so it took several weeks and several reminders to get action ;-]. + show leadership, build consensus among the warring factions and come up with a set of ideal UX designs to sell to development. NB. worth checking that you have buy-in from whichever developers you want to work on those. + start working on improving the UX - all constructive patches are welcome - I've not seen any sane UX patch rejected in recent time. > There is a very-condensed version of my feedback and proposals : > http://mr-consultant.net/blog/2013/04/thoughts-about-libre-office-design-process-part-9-conclusion/ So - given the relative impossibility of: "the TDF should define rules to be sure that every part of the roadmap is executed (ie important functionalities are developed on time instead of developers working on non-important functionalities)" I strongly suggest another set of thoughts: * Designers should lead by inspiration, good relations with developers, and producing designs so compelling that developers cannot resist taking time to implement them :-) * Designers should respond quickly to interest and questions from developers to ensure that they build good relationships and are at the forefront of the latest feature development Beyond that, there is nothing stopping the design team coming up with a set of proposals for where to take the product; it would be ideal if there was even buy-in from lots of designers rather than a series of fragmented efforts. It would be even better if those proposals were sane from a development perspective: you don't need a coder to stand beside you holding your hand to realise that when you start with a blank sheet of paper for your design - it is most likely not going to fly in linear time. Designers also need to recognise that currently many full-time developers are employed by fixing and sustaining enterprise usage of LibreOffice, so "suggestion #1 - cut out all the features" is a total non-starter, no matter how sexy the design might look; a better start is "suggestion #1 - conditionally hide many of the power features" for example. Anyhow - some interesting thoughts; thanks for writing them down, even if this seems like yet another iteration in the endless re-learning of: + designers cannot -tell- developers what to do, they can only work with and educate hackers constructively (or do some hacking themselves" + we emphatically -do-not- have a feature-based released schedule - it is time-based, and we stop for ~nothing. Which are really bed-rocks of the development process and successful inter-team interactions. They are also not unusual - GNOME has a very hard (release to the minute) time-based release schedule, and has also manged to do significant UX change (not all of which has been viewed positively FWIW). My personal analysis is that this is fundamentally a resource problem - and that growing the developer community while (hopefully) UX guys interact positively, produce good friendships across the divide between UX and hackers, and contribute to each others worlds will eventually steer us in a positive direction. It may not be a "big-bang-don't-release-until-we-changed-everything" direction - but hopefully it'll be fun getting there :-) Today there is nothing stopping any arbitrary wonderful UX design from getting implemented beyond: the need for designer/coder leadership-cum-consensus, and of course the resources to implement it. I'm also more optimistic - I've seen some great UX work happen in eg. the Android Remote - which ends up looking (at least to me) very much like the designs I saw - having said that, some work will happen in GSOC 2013 (I hope) to make the designs incrementally better there - hopefully with UX input on those. I've also seen some designers like Mirek, Astron, Alexander and others buckle down and do some great work, interacting with developers, building good relationships, and working closely with them on new features and changes: it'd be great to see more of that. That's my 2 cents anyhow, ATB, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted