Re: [libreoffice-design] User Research

Þann fim 16.jún 2011 11:29, skrifaði Björn Balazs:
> (sorry for evtentual double posting - got the wrong mail-account before...)
>
> 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

Many interesting/useful ideas here.
As Björn says, gathering data does not help much if there's 
not a good way to handle it and derive constructive analysis 
from it. Somehow centralizing data from such varied 
sources/methods could be quite a task.

Has already been mentioned:
- direct feedback from inside LO
- online user surveys
- user polling system (on new/changed features)
- existing usage data [1]
- (future?) installation/download data [2]

I can imagine additionally a couple of ways to get 
user/usage data:

- Usage tests/surveys for institutions/enterprises/other 
group deployments. That is, something sysadmin/IT-staff can 
ask their users to participe in, maybe focusing also on 
their own deployment (being useful for them directly).
- Self tests; e.g "My word processing skills - basic level" 
or "Test your spreadsheet magic - advanced". People seem to 
like such tests, maybe it appeals more to the 
games/sudoku/crossword population.
- Timing some defined actions/workflows in differently setup 
alpha/beta versions could give good indications on whether a 
feature change is a progression or not. Could be resource 
demanding (building/comiling several additional branches) 
but could become relatively easy with a 'skin-enabled' 
interface.

Just some thoughts, disregard if unrealistic.
Regards
Sveinn í Felli

[1]: such as 
<http://wiki.documentfoundation.org/File:FindAndReplace_UsageNumbers.png>
[2]: Will surely depend on how LO installs/upgrades will be 
handled in the future; diffs vs. full packages, 
installs/upgrades of single components, distribution 
specific issues, etc.


--
Unsubscribe instructions: E-mail to design+help@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