some feedback from a mobile application development team

Tue Jan 5 23:22:27 UTC 2016

On Dienstag, 5. Januar 2016 08:16:38 CET Dirk Hohndel wrote:
> Hi there,

Hi Dirk,
as the person in charge of the KDE Mobile HIG (and therefore also responsible 
for the usability of the Plasma Components), I'm very happy to get feedback 
from users of an actual working application using our components!

Since I am not a developer, I can only discuss our design choices, our 
developers are better suited to discuss the technical problems you 
encountered. 

So here goes my comment on the user feedback. Please bear with me, as I'll 
have to expand a bit on the reasoning behind the interaction with the action 
button:

> c) the user feedback (about 25 alpha testers on about 30 Android devices,
> we haven't gotten the iOS build to work, yet, as some of our dependency
> libraries are causing us trouble) is very negative on the action button.
> People find it very unintuitive and a solution looking for a problem.
> In my latest builds I have hacked our copy of the MobileComponents to
> simply disable the action button and instead added traditional three
> bar / three dot menus to the top bar - this was very well received with
> the testers. The context menu button (three vertical dots in the top
> right corner) only shows up when there is a contextDrawer. Tapping on
> either of the buttons opens the coresponding drawer.
> The Subsurface team would love to see an option to cleanly disable the
> action button in the MobileComponents.

First of all: It's fully understandable that Android testers like UIs the way 
that stock Android UIs are. That's what they're used to, that's what their 
muscle memory has learned.
Let me explain to you, then, why we diverged from the default Android 
behavior.
As a start, here are the relevant section from my blog post laying out the 
basic assumptions behind our design choices [1]:
---
Users prefer to interact with the center of the screen
As research [2] shows, smartphones are predominantly held upright (portrait 
mode) and in one hand, simply because that is the most convenient way to use 
it and it leaves one hand free e.g. to hold onto something while standing in a 
bus.

If we want an application to be used conveniently with one hand, we have to 
make sure that everything that is needed often can be reached with that hand’s 
thumb without having to reposition the hand (although the aforementioned 
research also shows that people do switch how they hold their phone whenever 
needed).

Regardless of the way users hold their phone, research [3] shows they 
generally are more precise in interacting with – and prefer to interact with – 
the center of the screen.

Based on these findings, the HIG recommends interaction patterns which do not 
require users to reach for the far ends of the screen (mostly the top), but 
give them on-demand controls near the center of the screen.
---

Given that, the context menu button in the top-right corner is almost in the 
worst possible place to reach (for left-handed people, it is literally in the 
worst possible place). Try reaching that button with your thumb when holding a 
5"+ phone with one hand, without changing the position of the device in your 
hand. Really, it's no fun.

What makes it even worse is that this button is the _only_ way to open the 
context menu on Android.
Therefore, the first and very obvious idea was to allow users to open the 
context drawer by swiping in from the right edge of the screen (since they do 
not have to reach to a corner for that).
However, we also know that not all users are comfortable with edge-swiping, 
which is why we looked for an alternative means to open the drawers (the 
primary way is still edge-swiping) for those people which are not.

That's where the Action Button comes into play. With Material Design, the 
"Floating Action Button" (FAB) has become an integral part of most stock 
Android applications (Mail, Hangouts, 
G+, Calendar, Maps, Photos, the thing is pretty much everywhere). There, it's 
used to execute a "main action" within an application (often creating a new 
object, but in Maps it's navigation and in Photos it's searching).

And, interestingly enough, the Material Design guidelines place that FAB in a 
position where it's easy to reach. So we thought "Hey, why not re-use the FAB 
as an alternative to edge-swipes for opening the drawers?".
And this is how this idea was born: We have a button in an easy-to-reach 
position which doubles as a main action button and an alternative to open 
drawers, mostly for those who can't use edge-swipe well.

So, dragging the Action Button is not "a solution looking for a problem", but 
in fact it is the answer to the problem that screen corners are hard to reach 
when you hold a bigger phone (which are becoming more and more common) in one 
hand.

I do agree with you, however - and this is also what I suggested within our 
team before - that on Android, people are not used to being able to drag the 
FAB, as it's inconsistent with what they expect from other Android 
applications. What they _are_ used to, on the other hand, is those buttons in 
the top bar.

Therefore what I'd like to see is that when our components are used within 
Android, they draw the buttons in the top bar (where they are - and that is a 
research-supported fact - hard to reach, but consistent with other Android 
applications) but leave edge-swiping as an easier-to-reach alternative for 
_both_ drawers (stock Android apps do it only for the left drawer, which is 
really nonsensical if you think about it). When the same application is run on 
Plasma Mobile, where people have learned how to use the Action Button-dragging 
from other applications, it should use that one.

The Action Button, then, should on Android not always be drawn, but only when 
it is actually used for an action, like in the stock Android apps.

I'm currently conducting usability tests with the components, and that's not 
"We ask people what they like", but I observe people to see what actually 
works well. The difference is that when asked what they like, people will 
almost always prefer what they're used to, even if it's inferior to a new 
solution.

Another thing I want to see changed in our components, though is the actual 
dragging interaction with the FAB. Currently one has to drag it pretty far to 
open a drawer, which defeats the whole "Not having to stretch your thumb to a 
corner" advantage and currently indeed makes it rather clunky to use.

I hope I was able to explain the reasoning behind our solution a bit better, 
while at the same time expressing that I support our components working in a  
manner that is similar to - but still better than - other Android 
applications.

So, what do you think?

Best,
Thomas

[1]: https://sessellift.wordpress.com/2015/10/15/behind-the-scenes-of-the-kde-phone-hig-part-one-basic-assumptions/
[2] http://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php
[3] http://www.uxmatters.com/mt/archives/2014/09/insights-on-switching-centering-and-gestures-for-touchscreens.php