Closed Bug 1042017 Opened 10 years ago Closed 9 years ago
Re-Examine the APZ kinetic Scroll Friction Animation
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?
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!
Summary: Re-Examine the APZ Kinect Scroll Friction Animation → Re-Examine the APZ kinetic Scroll Friction Animation
10 years ago
Component: Panning and Zooming → Gaia
Product: Core → Firefox OS
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.
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!
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.
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.
Hi Gordon, do we have bug numbers for the scrolling plans in comment 6? Thanks!
It's still in the early product planning stage.
This will be re-examined as a feature during the UX scrolling behavior review around release 2.2 planning.
From user testing, if we want perceived smoothness while scrolling, we have to fix this.
(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.
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.
9 years ago
See Also: → 1085404
Have you had a chance to try this out Gordon? Thanks!
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.