Joshua Tucker 's 'detecting hand posture' idea can be use like this.
right handed user will see 'go to the top' button on the right,and left handed user will see it on the left.
thank you, Joshua. It's brilliant idea!!!
Great work! That's what I'm talking about :). Very, very cool idea!
One thought though: have the top/left button float near your finger :). Use the pageY/clientY/y/etc. to place it within a general range near where you are touching down and scrolling and then justify it to the side you are on (using the detection you are using).
Or you could even use it as a quick scroll mechanism - performing an action on the floating button to go either down or up, not just up.
Joshua Tucker I'll try. Thanks.
Joshua Tucker proximity placements are generally a bad idea as you require the user to comprehend a pattern that is based upon their use-behaviour - it's simply to hard to predict and thus someone might be prone to accidentally push a button instead of scrolling,just because he changed his range of motion in one flick compared to the prior one.
This left-right placement as general accessibility practice is a neat detail.
Andreas Mitschke No doubt. I agree on those elements. While I am not necessarily contending my suggestions are the answer, but there are ways of approach that eliminate those problems. In the case of my own example, I display the options on one side and then lock them on that side until the menu is closed again. The proximity sensor does not have to fluctuate that significantly, no?
Even slight changes of position have shown that users tend to fail to adequately adapt to them without strenuous additional effort - so, they simply don't favor it over the common thing. There's been a NN study about a "comparable" hypothesis, not in mobile environment though. Should be worth a general study of thumb-depended interaction patterns. ^^
If we're talking of less than one button-size in position volatility, then the potential advantage of thumb/finger-to-action distance is kinda neglectable, yet is confusing to see a jumping button.
As a matter of course, this depends on your target audience, as always. If you can expect highly tech-affine users - way to go to apply experimental use patterns. However, if you encounter the common user, he'll probably not understand why the button changes it's position. Just hypothesis though... needs validation in any case I assume. ^^
So, this is more a case of usability and less of interaction design.
I totally dig a second button, let's say a "back to prior position" button or "to bottom" as you said. I also often see myself quickly swiping to top and then back to bottom, because the bottom content area often provides exclusive additional navigation elements.
Interesting! Makes sense. Happen to have a link to the study? And I love the dialogue so thanks for engaging :). Ever learning.
Buttons are not necessarily the answer either - if you don't need them, I think they are extra weight :). You could say calculate the velocity of a swipe versus a scroll and top/bottom scroll. So I could fling one direction and have it throw to the top or bottom without the need of an extra tap or gesture.
I search for it and send it to you if it's a public file.
The latter actually is standard behaviour of most touchpads in notebooks (synaptics). I lack the insight in xda or swift, though there might be a function for that already available as well.
Oh? I was just chatting with my dad and he was saying the same thing. I think we concluded it isn't often utilized because of its "touchiness. Maybe it could be improved?