[libreoffice-design] Re: [Libreoffice-ux-advise] Articles about LibreOffice design process

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


-- 
Unsubscribe instructions: E-mail to design+help@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