some feedback from a mobile application development team

[Thomas Pfeiffer]

On Dienstag, 5. Januar 2016 16:58:10 CET Dirk Hohndel wrote:
> 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 :-)

I'm foremost a human-centered design specialist, so incorporating user 
feedback into design is integral to my design work.

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

Conformity with expectations is one of the key principles of HCI, so I will 
always try to innovate while breaking with expectations as little as possible.
 
> > 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 .

Okay, fair enough. But I'm glad you still consider my point valid for people 
with smaller hands than yours.

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

There is a difference between edge swipe and regular horizontal swipes. All 
stock Android apps that have a left drawer use an edge swipe to open it (in 
addition to the button), but still happily use horizontal swipes to navigate 
e.g. between emails without conflict.
Edge swipes are really only from outside of the screen in, whereas regular 
horizontal swipes start from any other point on the screen.

The usability tests I've conducted so far showed no conflict between edge 
swipes and regular horizontal swipes (which we use heavily for back and 
forward navigation). Users only on very rare occasions accidentally opened a 
drawer while using horizontal swipes for navigation.

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

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

...and see my reply ;)

> 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

We could do that, yes.

> - allow the application to override the edge swipe functionality

See above.

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

You caught us here: Actually, this was our idea all along, we just haven't 
gotten around to design and implement them, yet. My usability tests so far 
also clearly show that this interaction needs a quick introduction. Once I 
showed users how it worked, they found it easy to interact with, so yes, we 
need those tutorials and will provide them.

And I also agree that this should be provided by the framework. In Plasma 
Mobile, the tutorial would come up directly on the first start of a new device. 
On Android, it should ideally be shown only the first time that any application 
using our components is used.

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

Ah, good :)

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

Thanks :)

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

This might indeed be a good compromise indeed.

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

I'd really like you to try out whether edge swipes for drawers and regular 
horizontal swipes for switching between dives can coexist in Subsurface as 
well as it can coexist in stock Android apps (see e.g. GMail or Photos), and 
if problems come up, I'd like to know what causes them and whether we can fix 
them.

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

Definitely! We need feedback from people who use our components in the real 
world. Design must not happen in an ivory tower, which is why I am eternally 
grateful that you are using our components even in their very early stage and 
are happy to provide feedback so we can continuously improve them. We really 
need that!