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

Hi Greg,

currently the project is not in the state to have a common understanding of 
who our users are and what they are supposed to do with the product(s) - and 
esp. the other way round: who are not our users and what are they not supposed 
to do with our product (Same with other important artefacts and the 
development process itself).

But good news: we are in the process of sharpening these issues. See our 
discussions on this mailing list about "Design Team Kick-Off". Perhaps you 
could jump in there and help to build up the essentials we need?


Am Dienstag, 12. April 2011, 09:58:56 schrieb Greg:
Hi Steve,

I'm not clear what you mean. I think it's incontrovertably true in all
circumstances that understanding what users require (and in this case, using
use cases as an expression of those requirements) should always precede
design and implementation - That IS good management! Otherwise, the danger
is that the development will be done enthusiastically. It may or may not be
right but will be left as 'done' while the enthusiasm is applied to the
next problem rather than address shortcomings baked in by not considering
requirements up- front.



Hi Greg.
I think what you describe is what is needed to drive LO from the
enthusiasts arena to main stream adoption.
But as the enthusiasts are doing all the work, it requires good
management or they will no longer be enthusiastic.

On 12/04/11 08:48, Greg wrote:
Without wishing to rain on anyone's parade or do unsavoury things to
campfires, I think there's been a lot of great design thought here
isolation of a good, hard, implementation agnostic think about
enumerating the real use cases.

When I say use cases, I don't mean anything to do with how to build
what looks pretty or cool but what REAL user goals need meeting,
tasks need doing and which actors are involved. Then perhaps a check
with users of Word processors generally (i.e. not posters on this
and not necessarily LibO users only) about how well the proposed use
cases would address any actual need.

Of course, some may prefer an agile approach, with epics, and user
stories and acceptance tests, &c. but I don't think LibO development
organised that way?

Until we've got some concrete, well written use cases validated with
users, the batting back and forth of designs and insiders'
seems a little premature.

Incidentally, I don't think the use cases should be constrained by
the current navigator's capabilities are.

I'm happy to get the ball rolling on the use case goals, to start
but I'll wait to see what everyone thinks first.



Voluntary Open Source Usability:
Commercial Open Source Usability:

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.