ActionButton mouse area issue

[Thomas Pfeiffer]

On Dienstag, 9. Februar 2016 08:13:39 CET Dirk Hohndel wrote:
> On Tue, Feb 09, 2016 at 05:04:44PM +0100, Thomas Pfeiffer wrote:
> > Yes, as Marco said, this change was a result form user testing. Two of
> > five
> > users I've tested with so far have tried swiping anywhere on the Action
> > Button's row to open the drawers, because they expected it to work that
> > way
> > and/or because they found it difficult drag from the center.
> 
> That is baffling but then, normal users baffle me all the time :-)

Exactly, users keep baffling designers and developers,w hich is why user testing 
is so important ;)
 
> > I understand your user's problems, however. Even though in fact, the
> > lowest
> > list item can still be reached by scrolling it up (a standard function
> > supported by the list component allows users to scroll the first and last
> > items of a list towards the center of the screen where they are easier to
> > reach), it is indeed strange to see it fully but not be able to interact
> > with it.
> That isn't useful in the way it's implemented right now, though. I can
> pull it up but it springs right back. So if my list has a "tap to open an
> item" feature, it is /really/ hard to open the last entry in that list
> (that's how I noticed this whole issue and started to track this down
> because I couldn't open the last dive in the list).

Oh, I didn't know that. See Marco's and my reply to that.
 
> > We are currently discussing various different options for solving the
> > situation.
> > - One is putting a semi-transparent layer over the action button's row, so
> > users can see that there are still more list items down there, but it's
> > obvious they can't interact with it unless they scroll further
> 
> That works if the "scrolling further" works.

Indeed.

> > - Another one is only grabbing horizontal swipes on the height of the
> > action button, but still letting everything else through.
> 
> That appears to be impossible with the current QML backend implementation.

Too bad :( Well, so we might have to cross that off :(

> > - A third is going back to a toolbar with buttons on the sides to open
> > drawers (while still allowing edge-swiping in addition)
> 
> I will humbly admit that I'm kinda in favor of that. While I understand
> the logic behind having the user interaction focused on the bottom, the
> ActionButton does not resonate well AT ALL with the Subsurface users. We
> have about 30 people that have tried it so far (maybe more) and have heard
> back not a single positive comment but eight different testers came back
> with anything from scepticism to outright hostility towards the concept.

My hypothesis is that there are two reasons for this:

1) There are still real problems with details of our interaction design. This 
does not surprise me, to be honest, because new interaction design ideas are 
never perfect in their first iteration. Never. If anybody tells you they can 
create a new interaction design paradigm which is perfect before any user 
testing, they are lying, plain and simple.

2) Humans' first reaction to change is always hostility (unless they are 
disciples of the Cult of Apple, that is). 

Now if we want to come up with something that is better than what Material 
Design does (and there is much room for improvement from there!), our task is 
to separate the aversion to change from the real problems and fix the problems 
to come up with something that makes people overcome their fear of change.

Even if the end result is an always-visible toolbar, I'd still put the primary 
action button more towards the center, and I'd still put the toolbar at the 
bottom, where it's much easier to reach.

> Subsurface-mobile has the global menu and context menu buttons in the top
> bar because so many of our users absolutely did not like to interact with
> the ActionButton.

I understand why you did this, but I really hope we can come to a design which 
is better than that, because this position of buttons makes it simply 
impossible to use an application with one hand (for people with smaller hands 
than yours ;) ).

> > There is one way you could greatly help us in finding out the best
> > solution: Marco could create a branch for each option, and you could
> > create create one APK of Subsurface with each branch. Then your testers
> > and we designers can conduct comparative user tests with each variant.
> 
> I'd be more than happy to do that.

Awesome!

> We are just about to open this to beta testing which I assume will get us
> several hundred users over the next few days.
> 
> > New ideas in user interfaces always need iterative testing and
> > fine-tuning, and we would love to work together with you on this.
> > 
> > Would that make sense to you?
> 
> Totally. We (the Subsurface developers) greatly appreciate the work the
> Plasma mobile team is doing. Subsurface-mobile would be nowhere near where
> it is today without being built on top of the mobile components.

Glad to hear that, and we are more than willing to cooperate with you and your 
users!
 
> All the criticism you hear from me (or through me) is always intended as
> "let's make it better" and not as "you suck". Email sometimes makes that
> hard to distinguish.

Don't worry, we're not taking it the wrong way. I appreciate that you're i a 
difficult position because you have to "sell" something to your users which you 
haven't designed.

I'm still hopeful what together we can find something which is genuinely better 
than what Material Design offers. Not that Material Design is bad in general, 
not at all. There are some great ideas in there, but some decisions seem to be 
based on the "lowest common denominator" instead of a search for the best 
possible solution.