[unconed]

Bouncy animations that overshoot just seem like a bad idea in general. The purpose of a UI animation is to guide the eye, but the bounce explicitly introduces a reversal of motion at the end before stopping.

Easing functions are just very cargo culty. We've had the same basic set that dates from the Flash era. Now there's an Apple variant that's just a parametric version of the same idea, but it lacks guaranteed continuity and it's even harder to control?

Personally I've had far better results using the repeated-lerping-towards-a-target trick, aka a true exponential ease. When stacked, you get a classic LTI (linear time invariant) system, and the math around how those behave is well established.

Classic hand-drawn animation does often use stretching and squeezing to emphasize and to create a sense of anticipation, but that's very different and always dependent on the specific motion. You can't automate that by making everything act like jello.

[pahgawk]

Hi, author here! When writing this, I was thinking more in the space of procedural character animation and motion graphics than UI animations. That's part of why I want a system with nice parameters, so that I do have the ability to fine tune and tweak the motion to fit the context. My background is in classical animation so it's something I might just keyframe by hand in a non-code context, or in Flash when it's easier to jump back and forth between code and non code. Although I think having it parameterized still can lead to interesting opportunities for variation in procedural animation!

[ipv6ipv4]

Overshoot is important for scroll views. Without the bounce, there is no feedback if you have scrolled to the edge or not. Early Android lacked the bounce, and it would invariably lead to users scrolling again to be sure they had indeed scrolled to the edge of the view.

[Jyaif]

> Early Android lacked the bounce

Early android had some visual feedback (a gradient that faded out) instead of the bounce, possibly because Apple owns a patent ( https://patents.google.com/patent/US7469381B2/en ).

Current Android still does not use the bounce, and instead stretches the content, which works well enough on the high resolution screens that we have now.

[ipv6ipv4]

Initial Android had scroll bars with no overshoot specific indication.

[Jensson]

Desktop doesn't have bounce and I prefer it that way. For mobile maybe bounce is more important since its less precise than a mouse, but point is that bounce is not obviously superior since on desktop the bounce just feels buggy rather than what you want.

[ipv6ipv4]

Desktop on Mac does if you swipe to scroll. It doesn't if you drag the scroll bar to scroll. On Windows, a scroll wheel doesn't bounce either. It doesn't need to when the scroll wheel itself provides physical feedback that you actually did something.

Touch interfaces tend to need some visual (or artificial haptic) feedback because touch itself is not enough.

[panic]

You can add the bounce as a second layer of dynamics on top of the exponential deceleration (this is how iOS scroll views do it).