Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi guys,

        So - first; when I read:

On Sun, 2011-07-10 at 11:57 +0200, André Schnabel wrote:
Anyway - what I really dislike from your further communication (your 
answer to Christoph) is the way you speak about "us" developers and 
"you" UX, QA and documentation guys. It's after all "we" who create
and develop LibreOffice.

        I don't think it's fair to Kohei - who has done more than most other
developers for pro-actively reaching out for *advice* from user
experience guys. ie. making himself vulnerable, and asking for trouble /
people to slow him down :-) [ and so far the interaction has been good I
think ]. My concern is, if we start beating him - I expect that to stop
abruptly: that is how people behave ;-)

        Secondly - I think Rainer's idea:

        "I will soon start a Specification together with Design and
         UX, we will see what arguments we get."

        is poorly worde for our community; a 'specification' sounds like a set
of mandatory demands for a set of things to do, and is handed to a
developer as a done deal. This is not how we work. Now - a set of
'Requirements' might sound better (but even that is a very strong term).
Perhaps we can come up with a suitably neutral term that reflects a
collection of research / advice that can assist a developer in achieving
the best outcome on a given feature. Also the set of formal roles
suggested here: https://bugs.freedesktop.org/show_bug.cgi?id=39068#c16

"@Regina: I added you in Spec with role "UX"
 @David: I added you in Spec with role "Cocumentation"
 @Christoph: I added you in Spec with role "Design"
 @All: Please feel free to remove if you do not want to be involved."

        Gives me the screaming heebie jeebies :-) We already have a product
that is the result of such a legacy, and we're trying to move rapidly
away from that, towards a project that can execute quickly, effectively
and attract developers to improve it.

        Now - there is no problem with doing research: what do competing suites
do, what do older / different versions do etc. expressing opinions for
what should be done, that is all helpful. What concerns me is the
language of control that the word 'Specification' (with all its
old-project baggage) implies.

        An alternative "including the developer in the process", is to expect a
developer to spend long hours negotiating detail with lots of
individuals to try to get something sensible he can implement, and is an
efficiency nightmare - and I think Kohei is completely right to want to
reject this.

        The UX team provide an invaluable advisory role to help developers
improve our user experience [ and of course they own and work on lots of
other eg. artwork / graphic branding pieces too ].

        We have the ux-advise list for this kind of interaction. The QA team -
particularly Rainer, are much appreciated for all the great work they
do, and their recommendations & preferences should be taken very
seriously - of course.

        But I personally, as Kohei, and a number of other ESC members, am
highly allergic to process in this area :-) We see it as having stifled
the will-to-live in those developers trying to improve the UI for far,
far too long.

        So - I personally am happy to see some paranoia in this area :-)

        HTH,

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.