ActionButton mouse area issue

[Dirk Hohndel]

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

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

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

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

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

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.

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

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.

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.

/D