Springs, easing, and the feel of weight

Weight is the single most underrated variable in interface motion. Get it wrong and everything else falls apart.

We describe interfaces as state. A component renders one way, then another. But animation never followed that model — the moment we wanted motion, we dropped a level into timelines, keyframes and physics engines.

The mismatch

We stopped describing what changed and started describing how it should move. That gap is where most bad interface animation comes from: motion that is authored separately from the state it is supposed to explain.

Animations can be decorative if they don't get in the way — but their primary goal is to communicate what's happening.

What good looks like

A good transition answers three questions: what changed, where did it come from, and where can I go next. If a motion answers none of those, it is decoration and should be cut.

Duration is the easiest thing to get wrong. Anything under 120ms reads as a jump cut, anything over 400ms reads as latency. Most interface motion belongs in between, with a spring rather than a fixed curve.

In practice

Start from the state diagram, not the animation. Write the two renders first, then ask what the browser should do in between. The best motion work usually ends up being less code than the version you tried first.