[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    Talking to users (Re: "Big picture" design one release cycle ahead?)
From:       Björn Balazs <bjoern.balazs () user-prompt ! com>
Date:       2012-10-29 10:33:38
Message-ID: 3059508.Xq7vqlRCju () rechenknecht
[Download RAW message or body]

Am Samstag, 27. Oktober 2012, 21:58:38 schrieb Thomas Pfeiffer:
> On Saturday 27 October 2012 18:37:56 Aaron J. Seigo wrote:
> > On Saturday, October 27, 2012 10:55:37 Bj=F6rn Balazs wrote:
> > > We would probably need dot releases after each sprint (and hence have
> > > a shippable product after each sprint)
> > =

> > doing a proper release after each sprint will kill our productivity due=
 to
> > the amount of developer manpower we have available to us. thankfully,
> > releases should not be necessary as people can simply update their tabl=
et
> > in-situ using zypper. so we can simply refresh the build repos on OBS so
> > those who are participating with us can follow development.
> =

> Agreed. We won't need proper releases with all the fuzz. That's the big p=
lus
> of having an always releasable master: When we work with users, we can ju=
st
> ask them to zypper up from master without risking the loss of data / cats=
 /
> hamsters / grandmas.

Sounds good. Just one question following my reply below...

> > > and we would need to implement
> > > some way of talking to the users (best would probably be directly
> > > through the product).
> > =

> > do you have a concrete concept of what this might look like?
> =

> From my perspective, ideally we'd have a group of users interested in
> participation (but not necessarily programming) who we interview and do
> usability tests and surveys with etc.

I strongly belief in talking to the user directly through the product, e.g. =

asking to answer some questions, subscribe to a user mailing list,... - we =
can =

figure out what we like best. =


To my mind this is the only way to a least have a potential to talk to some =

sort of representative users. This excludes the desired target groups, whic=
h =

Inge was addressing. We will have to use other techniques to model the not-
yet-users, e.g. we could use personas for that. So we do not loose them.

But it does carry some advantages, like:

- real users can report easily about real experiences (like David T. obviou=
sly =

feeled he wanted to that in reply to this thread, I think a lot of users (e=
sp. =

the tinkerers) will have the same wish)

- if such a mechanism is established we will get to know where we are in te=
rms =

of the user base and our desired target group (Did the control industry hop=
 on =

yet?)

- people feel self efficient, because they influence the product - hence th=
ey =

will have a much more positive attitude towards PA and might even do some =

marketing and such...

- if numbers are getting larger, we do not have to bother the same user all=
 of =

the time again


Now my question: If we do so, we would need to talk to people using a certa=
in =

configuration / version of the software to get the right feedback (and peop=
le =

will not be able to tell us the correct version number of their software). =

This is where I drew the idea of dot releases from. Would this also be =

possible when we use the Master branch?

Cheers,
Bj=F6rn

> _______________________________________________
> Active mailing list
> Active@kde.org
> https://mail.kde.org/mailman/listinfo/active
-- =

Dipl.-Psych. Bj=F6rn Balazs
Business Management & Research
T +49 30 6098548-21 | M +49 179 4541949

User Prompt GmbH | Psychologic IT Expertise =

Gr=FCnberger Str. 49, 10245 Berlin | www.user-prompt.com =

HRB 142277 | AG Berlin Charlottenburg | Gesch=E4ftsf=FChrer Bj=F6rn Balazs
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
[prev in list] [next in list] [prev in thread] [next in thread]