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:
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.
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: http://www.OpenUsability.org
Commercial Open Source Usability: http://www.OpenSource-Usability-Labs.com
Unsubscribe instructions: E-mail to email@example.com
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/design/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-design] About the Navigator · Greg
Re: [libreoffice-design] About the Navigator · planas
[libreoffice-design] Re: About the Navigator · frankt
- Re: [libreoffice-design] About the Navigator (continued)
Impressum (Legal Info)
: 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