Feedback from a user's / usability engineer's perspective

[Aaron J. Seigo]

On Sunday, August 21, 2011 22:27:43 Thomas Pfeiffer wrote:

cool that you got it running and some time to review ...

> - Switching applications just feels too slow. The user has to pull the 
topdrawer either all the way down and all the way up again - which takes 
quitesome animation time to do,

in fact, that's precisely what one should not have to do :) if the user feels 
this is necessary, then the UI is failing them in some way.

> or pull it to the "application switcher position
> - which is pretty hard to do since in my experience, most of the time it
> doesn't "click into" that position.

i've noticed this as well, and the fix is probably fairly simple: decrease the 
amount the panel is needed to be dragged to cause the "click into position" to 
trigger. right now one has to basically "overshoot" to get it to click into 
place, when probably it should only be needed to be dragged down a dozen or so 
pixels to cause it to click open.

> it would
> still be two actions which don't easily combine into one "flow" for an
> action that users might want to do pretty often in some situations.

i'd hold off on that assessment until the "click into" is working optimally, 
since that highly affects the ease of use of this feature. keep in mind that 
this is also a trade-off between screen space usage and access ease.

> The general idea of pulling down the panel doesn't seem too strange
> orproblematic, it's just that

> we need to enable the user to switch
> applications with one continuous movement in order to make it feel less
> "cumbersome".

suggestions?

> - Adding resources to an activity seems rather inflexible. 

> The user needs
> more control over where to actually put the resource instead of the system
> adding it "somewhere".

can you explain why they need this control, what it achieves and what the 
current approach prevents from happening? (not saying your assertion is wrong, 
but hoping to encourage supporting information rather than assertions made 
without support which often leads to misunderstandings)

> When the user starts dragging a resource, fade
> the window out until she has placed the resource on the activity (or
> canceled the action by dropping it over the panel). Fade it in again
> automatically afterwards. 

i've used some touch interfaces that do similar things and they have tended to 
feel "clunky" as things are moving in and out of view / context while the user 
is expected to then know what they are to do next.

it should be fairly easy to do some user testing on which kind of approach 
would work better for more people, however.

> - Why is "add resource" and "configure activity" activated using a button?
> I'd say they should be done in a drawer as well to keep them consistent
> with the rest.

corolary: we should be careful not to end up with lots of drawers everywhere, 
making it harder to user and learn. keeping the usage of the drawers to 
special features that are not already in context to the current activity seems 
good.

> - I'm not sure if it's only in the Meego image, but at least here I just
> can't find a way to turn the darn thing off ;) In the end, I have to press
> the power button until it switches off 

there's the logout / poweroff widget that you can add to an activity. it isn't 
the most elegant approach .. what we're lacking still is a "system control" 
application that most devices seem to have these days with quick access to 
common settings and things like "turn the device off".

> or have to use Konsole with a USB
> keyboard ('cause the virtual keyboard isn't shown for Konsole).

it does in the current packages.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/active/attachments/20110822/10392977/attachment.sig>