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 growi
