[Libreoffice-ux-advise] Articles about LibreOffice design process

[Michael Meeks]

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.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot