Springs and duration
Duration is the part of an animation people argue about most and think about least. Emil Kowalski’s numbers are consistent across everything he has written. The rule of thumb from You Don’t Need Animations is under 300ms for UI animation. The skill excerpt he shows in Agents with Taste breaks that down: micro-interactions 100 to 150ms; standard UI such as tooltips and dropdowns 150 to 250ms; modals and drawers 200 to 300ms. The fuller table in his skill file is slightly more generous at the top end: button press feedback 100 to 160ms, tooltips and small popovers 125 to 200ms, dropdowns and selects 150 to 250ms, modals and drawers 200 to 500ms, and marketing or explanatory animation can be longer. Exits can be about 20 percent faster than entrances. The course’s own agent rules say the same in plainer words: never longer than a second unless it is illustrative, and most around 0.2s to 0.3s.
Two of his rules keep the table from being mechanical. Larger elements animate slower than smaller ones, and duration should match distance: longer travel, longer duration. In Train Your Judgement the example is a full-screen mobile menu, where the sub-300ms rule that serves tooltips and buttons makes the menu feel jarring because the distance is so much larger. Bigger elements are heavier, he writes, and should animate slower, “the same way a truck takes longer to stop than a bicycle.” The drawer he built, Vaul, is the production example: 500ms, because that is what mimics the iOS sheet, with the Ionic curve from the last section.
The other way to set duration is to stop setting it. A spring is described by physics rather than by time. Emil’s skill file says springs feel more natural than duration-based animations because they simulate real physics and settle according to their parameters rather than a clock. In Great Animations he points at the Dynamic Island, which “feels natural, almost like a living organism,” and contrasts it with web apps where changes happen instantly, which feels artificial because nothing in the world around us appears or disappears instantly. He built a visualizer with stiffness, damping, and mass sliders for that post, and the playground below is the same idea. Drag stiffness up and watch the curve tighten; drag damping down and watch it overshoot. Then press play and notice that the dot on the track and the curve above it are one equation.
His configurations are modest. The skill file gives two ways to write a spring in Motion: { type: "spring", duration: 0.5, bounce: 0.2 } when you want to think in time, and { type: "spring", mass: 1, stiffness: 100, damping: 10 } when you want to think in physics. Bounce, when used at all, stays subtle, 0.1 to 0.3, and he says to avoid it in most UI and save it for drag-to-dismiss and playful interactions. Train Your Judgement makes the same point as a matter of brand: a bouncy accordion feels approachable in a learning app and unserious in a finance app, so “no bounce should be your default.” In Good vs Great Animations he also shows the narrow case where a spring rescues a non-animation: a component that follows the mouse feels artificial when it snaps to the pointer, so he runs the value through useSpring, and then immediately qualifies it. That works because the effect is decorative. A functional graph in a banking app should have no animation.
The last reason to prefer springs and transitions over keyframes is that they can be interrupted. The clearest account is in Building a Toast Component. Sonner first used CSS keyframes, and when toasts were added quickly the older ones jumped to their new positions, because a keyframe animation cannot change its end value while it plays. CSS transitions “can be interrupted and retargeted, even before the first transition has finished,” so he switched. Train Your Judgement generalises it: for anything that can be toggled rapidly, menus, modals, accordions, drawers, prefer transitions over keyframes. His skill file adds that springs keep their velocity when interrupted, where keyframes restart from zero. Great Animations gives the reason in terms of feel: interruptibility lets the user change the state at any moment while the motion stays smooth.
Put together, the guidance is this. Start from the table, then let distance and size pull the number up or down. If the element moves in response to a gesture or can be toggled fast, use a spring or a transition so the motion survives being interrupted. Keep bounce near zero unless the product is playful on purpose. And one rule he repeats across the skill: asymmetric timing, “slow where the user is deciding, fast where the system is responding.”