Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm Unsatisfied with Easing Functions

davepagurek.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: I'm Unsatisfied with Easing Functions

#61

Post by jakelazaroff »

f33d5173 wrote: post #55
jakelazaroff wrote: post #38

Earlier quoted context omitted.

By "CSS version" I'm assuming you mean cubic-bezier [1], which definitely does not solve all the author's problems. For example, you cannot use it to create their third example (easeOutElastic), nor many of Apple's kinematic easing functions or the feedback control. [1] https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...

Yes, you can't use it to create those other functions, but you can use it to fulfill the authors purported goal in using those other functions. It also solves the deficiencies the author highlights in those other approaches. You could of course point to deficiencies in it and seek to resolve those deficiencies, but that wasn't how the article was structured.

I'm not sure why you think that? The author defines "easing functions" like this (which describes CSS's `cubic-bezier`):

> An easing function takes in a linear progress value, and returns a new progress value, but converted to nonlinear motion.

They then describe the problem with them in the section "Easing is not so easy", after introducing easing functions that are already more expressive than `cubic-bezier`:

> In traditional animation, the principles are just guidelines; you still end up creating new unique motion each time based on what acting the scene calls for. Easing functions in code don't quite give you the flexibility to do that.

Re: I'm Unsatisfied with Easing Functions

#63

Post by Bluestein »

mattkrause wrote: post #35
shermantanktop wrote: post #25

Earlier quoted context omitted.

I read the article as an unreasonably deep dive into something that few people care about as much as the author. I certainly don’t, but that’s what makes it good. That’s perfect for HN.

My only real beef with the article is that "Uneasy about easing functions" would have been a much better title.

Oh, you beat me to it, I see :)

Kudos.-

Re: I'm Unsatisfied with Easing Functions

#64

Post by SimplyUnknown »

I have the feeling that B-splines would be a good solution for this problem. Given that they have a continuous zeroth (i.e., the function is continuous), first, and second derivative, the motion will always be smooth and there will be no kinks. However, maybe it's moving the problem because now you must tune the coefficients of the B-spline instead of damping parameters (even though a direct mapping between these must exist but this mapping may not be trivial).

Re: I'm Unsatisfied with Easing Functions

#66

Post by ipv6ipv4 »

unconed wrote: post #3

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 cont…

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.

Re: I'm Unsatisfied with Easing Functions

#68

Post by Jyaif »

ipv6ipv4 wrote: post #66
unconed wrote: post #3

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 cont…

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.

> 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.

Re: I'm Unsatisfied with Easing Functions

#69

Post by magicalhippo »

bhk wrote: post #8

Oscullation/"anticipation" in transitions is so gimmicky and cartoonish. Living things don't move like that, and mechanical things don't unless they are broken, chintzy, or poorly designed (underdamped).

In my view we most certainly do, though of course not all the time.

Oscillations typically happen when moving quickly and then stopping at a certain position.

A prime example is the ISSF 25m rapid fire pistol event, where you start with the pistol pointing down at 45 degrees, and within 8, 6 and 4 seconds have to raise the pistol and take 5 aimed shots.

Beginners will often find they oscillate vertically above and below the center of the target as they raise the pistol, and it usually takes a fair bit of practice not to oscillate. This is more pronounced at the rapid pistol events due to the tight time constraint forcing them to move quickly, especially at the final 4 second round.

Another example is gymnastic rings, especially when they go from a swinging motion to stopping vertically or horizontally.

Anticipation-like movement often occurs when we want to get a bit of extra momentum. For example, casually tossing a base ball or tennis ball often results in a bit of backwards movement first, before the main swing. Typically it's one smooth movement.

Post reply on HN