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? Best, Björn 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. Cheers, GregHi 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. steve 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 in 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 it, what looks pretty or cool but what REAL user goals need meeting, what tasks need doing and which actors are involved. Then perhaps a check with users of Word processors generally (i.e. not posters on this forum 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 is 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' preferences seems a little premature. Incidentally, I don't think the use cases should be constrained by what the current navigator's capabilities are. I'm happy to get the ball rolling on the use case goals, to start with but I'll wait to see what everyone thinks first. Cheers, Greg
-- Voluntary Open Source Usability: http://www.OpenUsability.org Commercial Open Source Usability: http://www.OpenSource-Usability-Labs.com -- Unsubscribe instructions: E-mail to design+help@libreoffice.org 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