ActionButton mouse area issue
thomas.pfeiffer at kde.org
Tue Feb 9 16:04:44 UTC 2016
On Dienstag, 9. Februar 2016 12:06:37 CET Marco Martin wrote:
> On Monday 08 February 2016 11:48:24 Dirk Hohndel wrote:
> > I'm running into a pretty significant issues with the ActionButton:
> > Its MouseArea has an implicitWidth of parent.width. Which means that my
> > page will not receive any clicks at all in the horizontal band that
> > includes the ActionButton - so if the ActionButton "floats" above a
> > ListView, the bottom most entry in the ListView cannot be selected
> > (unless it happens to be taller than the icon size).
> > The issue appears to be that onClicked ALWAYS accepts the event. Even
> > though the onClicked code simply returns if the click wasn't on the
> > button (the math for that was just recently fixed) - the ListView
> > "behind" never receives a click.
> hmm, a problem is that from some user testing, it seems that users expect to
> be able to drag that button from any place in the whole bottom strip,
> rather than interact with the contents behind the button.
> Thomas may explain this better
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.
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.
We are currently discussing various different options for solving the
- 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
- Another one is only grabbing horizontal swipes on the height of the action
button, but still letting everything else through.
- A third is going back to a toolbar with buttons on the sides to open drawers
(while still allowing edge-swiping in addition)
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.
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?
More information about the Plasma-devel