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

Þ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
- 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
- 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 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?


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.


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
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

Such a registration-based system can also control for multi-votes.


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.
Sveinn í Felli

[1]: such as <> [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
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.