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

List:       kde-usability
Subject:    Re: New project: Aktions
From:       Ellen Reitmayr <ellen () kde ! org>
Date:       2006-03-22 11:03:52
Message-ID: 200603221203.59919.ellen () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 21 March 2006 00:40, Zak Jensen wrote:

> Maybe collecting statistics overall is not a good idea, then. I can
> see places where it could still be quite useful. For instance, one
> could collect generic statistics from a wide audience, then look for
> patterns which closely match limited test groups. Or, one could use it
> to find patterns in the generic statistics, then attempt to figure out
> why it occurs so much (possibly by giving questionaires out to limited
> test groups).

> The above, of course, is mostly my idealistic ramblings, and a
> half-hearted defense of my project ;) Having read the next (<snip>'d)
> part of your message, I see the need for limited test groups.

Yes, that's my opinion, too. I don't mind collecting statistical data - the 
opposite is the case! I'd be happy to have good tools that support my work in 
a statistical way - in a *controlled* environment (the larger the better, but 
a representative sample of our target users).

what always makes me shrug are the words *anoymous* and *automatically*. With 
anonymous data, you won't be able to ask questions afterwards. and 
automatically mining the users' goals, tasks, thoughts and expactations from 
anonymous action tracking data that is not possible.


> > From a bunch of anonymous data, you will get several high and low peaks,
> > and sequences of actions. Without knowing about their tasks it's
> > impossible to know if actions were not used because they were not part of
> > the task they wanted to perform, or if they did not find them.
>
> However, you could, for instance, use it to identify places where
> functionality should be moved around. For instance, one of the initial
> uses of this toolkit could be to identify "KActions" which are in the
> wrong place... such as items on the toolbar that are seldom used.

sure, but still you need to find out if it wasn't used because the icon is bad 
and nobody understood it, because the toolbar is too crowded, or because it's 
really in the wrong place.

based on the tracking data, you can of course make assumptions why it wasn't 
used. but then again you are at the point you watned to avoid by statistical 
analysis: making assumptions ;-) 

however, if you combine the tracking with questionnaires, or additonally 
observe a part of the user base you'll get quite reliable answers to those 
quesitons.

> > Taking Thomas' example of
> > DnD in Konqui, you'll never know it the people don't do it because
> > they've already learned it does not work, or if they don't use dnd.
>
> You will be able to say that they don't use DnD, however. So, you can
> then ask a selected group why not in a tailored survey.

jupp, that's it :)


> > Even worse,
> > information about the user is missing! How do you know if the people who
> > sent in their data belong to your targetted user group? Maybe all your
> > data comes from the developers themselves, how should you know??
>
> The problem with any form of statistics is ensuring the group that you
> are analyzing is both statistically significant and random. We are
> well aware that, because Aktions features an opt-out, it will exclude
> a portion of the audience. We have 2 refutations to this argument:
> 1) We assume that the people who exclude themselves from Aktions will
> not skew the statistics... as they should be constituted of as random
> a population as the rest of the audience.
> 2) If the assumption made in (1) is false, then those who opt out have
> accepted the consequences of that decision--that the interface will
> not necessarially improve towards the way they use their computer.

hehe, yes, and that's very much the open source idea :)

regarding kde, i'm still not completely sure where we are heading to: some 
want to address the 'normal' users (conquer the desktop!), others say 5% less 
geeky users tthan our current user base. for the latter, the above approach 
would sure work, for the first... rather not. 
but that's merely a kde problem: if we don't know who our target users are, 
it's hard to find a representative sample. that's really really the most 
important decision we have to agree on.


> > And here we get to my second, even bigger concern: A software that is
> > *potentially* able to call home, is not trustworth for many users. I very
> > well remember when Microsoft XP was launched: The first thing everybody
> > who got a new PC running XP was told by his peers was to switch off the
> > 'call home' function. Still, people were unsure if it really was switched
> > off. If a software has the power to observe you and send the data to an
> > unkown recipient, a user cannot be sure if a simple button to switch off
> > the function really works.
>
> We did not approach this concern at all within our present
> documentation, because it was out of the scope of those documents.
> However, this is the predominant reason why we chose to make our
> project open-source. Users can inspect the source code themselves if
> they don't know if it is true to it's word. If they lack the
> capabilities to do this themselves, then they can pay someone else to
> do it instead.

This is again about the sample: As long as we target to improve the desktop 
for our and the rest of the oss community, i don't see too many problems 
regarding the trust. my concerns rather regard the 'normal' users, for whom 
we are just another part of the huge and invisible software industry. if they 
are watched by ms, and they are watched by us: What's the difference? 
(This argument only counts if you address non-community members.)

> Of course, we plan to have a little bit of muscle to back the claim
> up. Similarly to the Mozilla Project or the Linux Kernel, we were
> planning on using a trademark to back up the authenticity of our code.
> That trademark would be licensed in such a way that we could prevent
> people from tampering with the code and saying it was Aktions.

ok.

> > However, KTips is another thing. In applications where you know about
> > weaknesses of the interface that can't be fixed by the one or the other
> > reason, you might specifically support the user. If he uses some bad
> > workarounds we know that are likely to occure, we can tell the user.
>
> I was thinking it could be used to help customize the toolbars of KDE
> as well. Imagine an applet that changes from a star to an exclamation
> point (or something similar) maybe one or twice a day (at most). If
> the user clicks on the applet at this point, an extender comes out
> saying (maybe) "You seem to use Print Preview often. Would you like me
> to add it to your toolbar?". Or something similar. The idea is to help
> while being as unintrusive as possible. (It doesn't bounce, jiggle,
> etc... and stays out of the users way... if they turn it off, it
> doesn't pop back up, etc.)

Sounds very interesting :)
maybe one might include it into the nested help stuff (user is guided from 
hints in the interface to more extensive context-based information to the 
manual, so he gets stepwise more information).

cheers,
/el


-- 

Ellen Reitmayr
KDE Usability Project
usability.kde.org

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


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