Bjorn, On Thu, 2011-06-16 at 13:27 +0200, Björn Balazs wrote:
> Hi Christoph, Phil, dror, * > > The discussion goes excatly into the right direction - but I would like to > actually do things step by step, and not not doing anything right now because > there is a far goal we would like to reach sometime. So please slow down and > take it one step at a time :) > > What do I mean? > > The first step would be to actually start talking to users. This is what I > try to intend right now. This should be purely voluntary, un-obstrusive and > will for sure be biased in the one or the other way. But it is also done > without great effort from our side. > > This way we can gain experiences with talking to our users. > > In the course of these surveys we can then (user-centrically) evaluate the > acceptance of other ways of involving users into the development. > > As it has been discussed in this thread this mainly divides into two > sections: > - We will need to install a direct feedback into LibO. This should aim at > users reporting problems, wishes, but also positive feedback and targets all > existing users. The trigger for communication here is the user. > - We will need to install one or more ways to quickly solve questions arising > during development, e.g. to user-centrically decide between two options. The > target here are existing as well as potential users. The trigger for > communication here is the (UI-)development team. > > These are channels of communication between users and developers. On these > channels communication needs to be goal directed, as dror mentions. So each > survey needs a goal and needs to be quality assured in order to not-piss-off > participating users (They will be lost forever!). > > To pick up other examples: > - If we want to do online focus-groups, we can recruit participants via these > channels. > - If we want to set up a group of lead-users, we can recruit them via... well > you know :) > > But it does not stop there. We will e.g. need a way to store and handle the > incoming data. So doing anything just quick and dirty will not work out in > the end. So my advice is to slowly but steadily go on on this topic. > > > If you - the team - agrees, I would very much like to volunteer and take > responsibility to drive this process step-by-step towards the far goal of > establishing a good communication between team and user - or even better: > make the users part of the team. > > As it happens, I do this kind of work professionally and via > OpenUsability.org with quite some experience in Free Software. As well I am > having fun doing so and I am working on a tool, that will help us and other > Free Software as well on solving the above mentioned issues. > > So what do you think? > > Best, > Björn > > Am Donnerstag, 16. Juni 2011, 15:17:57 schrieb Phil Jackson: > > Hi Dror > > > > That might work by restricting voting to unique users. > > > > I think it will be problematic trying to control groups though - how do > > you identify a group and associate users with it? > > > > There will always be people who contribute more than others, sometimes > > out of genuine interest, sometimes in order to unduly influence outcomes. > > > > If we get large samples of feedback, I would think that this would > > negate having to make decisions about the numbers and groups and what > > they actually mean. It would be simple enough to set a minimum number of > > entries before the decision is accepted, much like a citizens' referendum. > > > > Cheers > > > > Phil Jackson > > > > On 6/16/2011 1:26 PM, drorlev wrote: > > > Hi Phil, > > > > > > What you suggest (a built-in list of proposed changes to choose from) > > > seems very interesting to me. > > > Personally, as a user, I would have liked it a lot. > > > > > > Still, one thing that bugs me is the possibility of sampling bias. > > > Assuming that there are several groups of LO users that have different > > > design requirements, the worry is that some groups will contribute to > > > the > > > survey more then their relative share in the general users population. > > > > > > A possible way to control for this might be to have users who wish to > > > contribute register to an account in which they have to provide some > > > demographic data. In order to influence, one will have to register and > > > tell a bit about him/her-self. > > > > > > This will enable, first, to look for different user-groups (in terms of > > > usage preferences) and then adjust the poles by demographic statistics > > > (for example, if the users population has about the same amount of > > > small-business users and students, but it turns out that students are > > > much more active in sending their preferences, the survey analyst can > > > weigh each contribution by group-membership weight in the general users > > > population). > > > > > > Such a registration-based system can also control for multi-votes. > > > > > > HTH, > > > dror > > > > > > -- > > > View this message in context: > > > http://nabble.documentfoundation.org/User-Research-tp3067418p3070307.ht > > > ml Sent from the Design mailing list archive at Nabble.com. > > -- > Björn Balazs > Leitung Analyse, Design & Test, Gesellschafter > _____________________________________________________________________________ > > Wir binden Anwender in Entwicklungsprozesse ein. > _____________________________________________________________________________ > > Apliki > Psychologische IT-Beratung > Tempelhofer Ufer 1a > 10961 Berlin > > Fon +49 · 30 · 99277999 · 31 > Mob +49 · 179 · 4541949 > Mail bjoern.bal...@apliki.de > Netz www.apliki.de > _____________________________________________________________________________ > Apliki GmbH & Co. KG, Berlin, AG Charlottenburg, HRA 39114 > > Persönlich haftend: > Apliki Beteiligungs GmbH, Berlin, AG Charlottenburg, HRB 104921 > vertreten durch: Steffen Eßers, Björn Balazs > +1 -- Jay Lozier jsloz...@gmail.com -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org 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
