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

[Thomas Pfeiffer]

On Mon, 22 Aug 2011 08:45:32 +0200, Aaron J. Seigo wrote:
> On Sunday, August 21, 2011 22:27:43 Thomas Pfeiffer wrote:
>
> cool that you got it running and some time to review ...

It's nice to see my suggestions considered and discussed :)

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

Yes, completely agree. And we already know where it is failing, see 
below ;)

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

I'd need to try the "fixed version" to see if that does the trick, but 
I can
imagine it working much better if changed that way.

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

I don't mean to abandon the pull-out thing in general. But compare it 
to the
activity switcher: You can switch an activity all by using your right 
thumb
while holding a tablet because everything is reachable by it. If your 
device
is light enough, it might even be possible while holding it with one 
hand.
This is not the case for the task switcher: It can't be used with one 
thumb alone.
I think that's why it feels so much more cumbersome.

>> 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?
>
Maybe we can put the task switcher in another drawer to the
left or right? Or maybe integrate it somehow with the activity 
switcher?
I'd just like to see the same interaction pattern used for both 
switching the active
activity and switching the active task, also because they are pretty 
similar
semantically.

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

The first thing is that after adding a resource to an activity, the 
user simply does
not know where it appeared and has to specifically look for it. This 
could
be alleviated by somehow highlighting all newly added resources with 
some
kind of animation, though.
The second point is that users might want to group their resources in 
some other
way than by type. This cannot be done by just selecting them and 
clicking "add".

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

Doing a comparison test for this would indeed be a good idea, as I 
don't know
for sure which one works better either.

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

Hm, you have a point there. Maybe I'm just a bit annoyed by the buttons
because they sometimes still don't work at first tap...

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

Definitely. Basic functions should not be hidden or hard to reach.

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

Good :)

I probably won't be able to reply again until Sunday as I'm on holiday 
for
the rest of the week (and I'm not enough of a geek to use my smartphone 
on
a camping ground in Belgium ;) )

Thomas