1042017 - Re-Examine the APZ kinetic Scroll Friction Animation

Status: RESOLVED DUPLICATE of bug 1095727

(Firefox OS Graveyard :: Gaia, defect, P3)

Description

[Mason Chang [Inactive] [:mchang]]

While working on Project Silk, I noticed that while having a fling animation with silk (e.g. scroll somewhat fast), people sometimes preferred the new silk behavior while others preferred the current scroll behavior. What emerged was that those who came from an iOS background preferred non-silk while those from android preferred silk. When broken down, it's because we have a lot more friction applied to slow scrolling down on APZ compared to android / ios.

This is more apparent on iOS as well. For example, scroll the contacts app versus scroll a webpage in Safari. There is much more friction for a webpage.

What we found is roughly attached from our naive observations with some partners as a way of slowing down a kinect fling.

1) iOS - Relative stable velocity with a fast slowdown in at the tail.
2) Android - Speeds up the fling then slows down fast.
3) fxos with a apz.fling_friction of 0.017
4) Current fxos - Exponential slowdown.

After some very sparse user testing, people from iOS liked 3 more than 4. Partners from an Android background also liked 3 more, but still liked (2) more. 

Can we take a look at our fling animation and our friction parameters to change this so that it "feels" more smooth. I realize this is totally subjective and there is no right answer, but how did we come up with our current exponential slowdown and should we change it?

Comment 1

[Mason Chang [Inactive] [:mchang]]

Attachment: rough sketch of fling animations across OS

Comment 2

[Mason Chang [Inactive] [:mchang]]

Hi UX! Any thoughts on how we came about our current kinectic scroll behavior? From my very limited user testing, (not any of our target markets), non-exponential decline for a kinetic scroll seems to be preferred. Have we thought about changing it? Thanks!

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Mason, once you sort out with UX if we want changes, and it turns out they're to be changes to APZ, please reset the bug back to Core/Panning and Zooming.  Right now, it's a feature request for Gaia.

Comment 4

[Jinho Hwang [:jeffhwang]]

Hi Mason, 
I'd like to make one comment about kinetic scroll friction.
Before V1.3, Gecko made similar friction animation to Android(Accelerate the velocity and then decrease).
And it was handled by BrowserElementPanning.
Since, B2G enabled APZ for all applications, every scrollable layer has current friction animation but it's not the same with the one from BEP made. 
So..  if you have the chance to change the scroll friction animation to another,please consider a consensus behaviour on BEP and APZ.

Thanks!

Comment 5

[Mason Chang [Inactive] [:mchang]]

Having a APZ friction of 0.017 was considered better by most around my small user testing. I will make a video and ask UX for review.

Comment 6

[Gordon Brander :gordonb]

Thanks Mason. What we have now is a careful balance based on:

* The fact that our fling force is 1:1 with finger movement
* Needing a nuanced fine-tune scrolling (related to the above)
* The physics model of overscroll (which does not handle exceedingly high fling velocities)
* Flywheel scrolling

Basically, because fine-tune scrolling is difficult with lower friction in our current physics model, we use flywheel to augment it.

Where we want to go in 2.1:

* Tune flywheel for faster scrolls.

Where we want to go in 2.2 and beyond:

* Fling force is curved... Hard flings are faster.
* Nuanced fine-tune scrolling should be easier (given above).
* A physics model for overscroll that handles high velocity cases better. We have ideas here.

Comment 7

[Mason Chang [Inactive] [:mchang]]

Hi Gordon, do we have bug numbers for the scrolling plans in comment 6? Thanks!

Comment 8

[Gordon Brander :gordonb]

It's still in the early product planning stage.

Comment 9

[Mason Chang [Inactive] [:mchang]]

This will be re-examined as a feature during the UX scrolling behavior review around release 2.2 planning.

Comment 10

[Mason Chang [Inactive] [:mchang]]

From user testing, if we want perceived smoothness while scrolling, we have to fix this.

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Gordon Brander :gordonb from comment #6)
> ...
> * A physics model for overscroll that handles high velocity cases better. We
> have ideas here.

Bug 1066888.

Comment 12

[Mason Chang [Inactive] [:mchang]]

The APZ fling_friction is actually set here - http://dxr.mozilla.org/mozilla-central/source/b2g/app/b2g.js?from=b2g.js&case=true#982 - and overridden from gfxPrefs.h. Try 0.0022 - 0.0026. I think I liked 0.0024 or 0.0023 the most.

Comment 13

[Mason Chang [Inactive] [:mchang]]

Have you had a chance to try this out Gordon? Thanks!