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

List:       kde-usability
Subject:    Re: E-Mail Scrolling in KMail/Kontact
From:       Sven Burmeister <sven.burmeister () gmx ! net>
Date:       2005-03-23 18:48:39
Message-ID: 200503231948.41400.sven.burmeister () gmx ! net
[Download RAW message or body]

Hi!

Am Mittwoch, 23. März 2005 19:28 schrieb seele@obso1337.org:
> your suggestions would not apply to a user test.  you simply want to tell
> x number of people x number of ways to use and interface and somehow judge
> which way is better.

Somehow? Set up x groups give them different ways, make them switch, ask 
again, that is how to find the best. If something is better than something 
else but needs a hint, you would suggest to take the worse instead of giving 
a hint?
As I said, what you test is just what people are used to (which is most 
certainly not always the best) unless you get at least a group of people who 
never used anything else before, your findings do not determine what is best, 
but you rely on people being used to x or y.

> a user test isnt a test of how well a user uses an application.  a user
> test is a test of the interface.  you do NOT tell the user how to use the
> interface (such as telling them what keys they can use to perform the
> test).

Of course you do, how do you think you know how to use the mouse? Because it 
was told you, it does not mean that you have to hear it, but be hinted to it, 
please read the article about what is intuitive. Placing a bar at the top of 
the header-list telling the user how the navigation works is absolutely 
valid. As there is no bar yet, you have to tell them, i.e. speak to them.

> you give the user a set of tasks to perform on the interface and 
> allow them to perform them however they want.  if they choose to go to
> help and lookup keyboard shortcuts, so be it. if they find
> search-and-destroy techniques more comfortable, thats fine.

If they are used to an interface your data is biased.

> in order to specifically test the arrow key issue in this thread, you
> would engineer tasks which would require this kind of interaction.
> encourage the user to explain what they are doing, why they are doing it
> and how they feel about it.  if they click through messages, are they more
> comfortable using a mouse or did they feel uncomfortable using the
> keyboard?  if they use the keyboard to scroll through messages, how many
> errors (wrongly pressed keys) did they recover from before they figured
> out what to do.  are they comfortable with that or are they just coping
> with the interface.

Again, giving hints is what makes an GUI intuitive, please read the article.

> user tests are one-time.  there is no re-evaluation or practice run.

> > Otherwise you will have the application and experience with another
> > client influencing the prefered keys for navigation. So you would not
> > test which one
> > is best but which they are used to more.
>
> arnt most of your current and prospective users going to be familiar with
> email in some way shape or form?  i think the fact that users will have
> previous email experience is irrelative.  were testing the interface, not
> the user.

You will just test what people are used to. Any previous knowledge of how to 
handle an email-client will bias tha data, i.e. you have to at least make 
them switch in order for them to make a valid comparison.

Sven
_______________________________________________
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]