some feedback from a mobile application development team

[Dirk Hohndel]

Hi Thomas,

> On Jan 5, 2016, at 3:22 PM, Thomas Pfeiffer <thomas.pfeiffer at kde.org> wrote:
> 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!

Awesome - a designer who wants to hear feedback from users... I cannot tell
you how refreshing that is :-)

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

Not at all - that's very useful to understand

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

Which, based on the principle of least surprise, to me was an important
part of the equation. I went through the Gnome 2->3 disaster, err, migration
and had endless discussions with designers who did NOT want to hear
feedback from users... and clearly did not understand the principle of least
surprise.

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

So I have two 6" devices (Nexus 6p and iPhone 6+) and use both of them
single handed and have no problem reaching either corner (happy to provide
video evidence), but I will admit that I have really big hands and that I'm well
aware that this is a big problem for most people, so this is a very valid point.

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

Side note: I am not a huge friend of the side swipes being used for the drawers.
I find swipes a great way to do navigation. There are a bunch of email applications
where swiping left and right you can move to the previous / next item in your
mailbox - something that I was hoping to adapt on Subsurface-mobile: if you look 
at the details of a dive, swiping sideways will get you to the previous / next dive
in your dive list.

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

OK, maybe that wasn't a nice way to phrase this :-/ -- my apologies.
But fact is that we had pretty unanimous feedback that people had not the
slightest idea what that button was there for. We had two different users 
assume that this button was to move to the previous / next dive :-)
But the user interaction "to open a menu, move this button sideways"
seemed utterly perplexing to everyone.

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

Yep.

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

See my comment above on the edge swiping...

What do you think about this solution instead:
- on Android, draw the two hard to reach corner menu buttons
- on any OS, show the FAB with the arrows
- allow the application to override the edge swipe functionality

AND

Support a "first start" mode for Plasma Mobile Components based apps that
demonstrates to the user how things get used. So it shows a see through
finger that taps and holds (the pulsing circles around the touch area) the FAB
and moves it and the menus show up, and then shows that you could also
tap the menu buttons when on Android. It would be nice to have this "first
start" mode supported by the tool kit so that not every single app has to
implement something along those lines.

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

I'm well acquainted with usability testing. We have a team in my group at
Intel that does that :-)

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

You did a great job.

> So, what do you think?

I tried to show my thinking above. In summary I'm supportive of introducing the 
FAB as an easy to reach way to get to the drawers, as long as it's in addition to 
the  traditional ways to do so.
I'm not a fan of side swiping for the drawers because that prohibits what
I find more intuitive and more useful application of the side swipe gesture.
Either way, I'd love to stay engaged with you and the Plasma Mobile developers
to create the best possible user experience for our users.

/D