Interaction And Motion

Interaction & Motion

Motion is not decoration. Every animation answers a question the user is silently asking — Did that work? Where did this come from? What's happening now? What's most important? If a motion can't be tied to feedback, orientation, status, hierarchy, or earned delight, cut it. Gratuitous motion is latency you chose to add.

Why motion exists (pick one before you animate)

Rule: if you can't name the purpose, you have a bug, not a feature.

Duration scale

Tie duration to distance, size, and importance, not taste. Bigger/farther = longer. Enter slower than exit (entrances orient; exits get out of the way).

Perception thresholds (Nielsen): ~100ms feels instant (direct manipulation budget). ~1s keeps flow of thought unbroken — anything under 1s needs no loader, just motion. >1s needs a progress indicator or the user assumes a freeze. Keep most UI transitions in the 200–300ms band; under 150ms reads as a glitch, over 500ms reads as sluggish.

:root {
  --motion-instant: 80ms;  --motion-fast: 180ms;  --motion-base: 260ms;
  --motion-slow: 400ms;    --motion-slower: 550ms;
}

Asymmetry: a menu opens at --motion-base (260ms, ease-out) and closes at --motion-fast (180ms, ease-in). The user already knows what's there — get it offscreen.

Easing

Easing communicates physics and intent. Linear is for nothing physical (use it only for continuous loops like spinners and progress). Real objects accelerate and decelerate.

:root {
  --ease-out: cubic-bezier(0, 0, 0.2, 1);
  --ease-in: cubic-bezier(0.4, 0, 1, 1);
  --ease-in-out: cubic-bezier(0.4, 0, 0.2, 1);
  --ease-emphasized: cubic-bezier(0.2, 0, 0, 1);
}

Direction is the #1 easing mistake. Entrances with ease-in feel like they stutter then snap; exits with ease-out feel like they drag and stick. Enter = ease-out. Exit = ease-in. Memorize it.

Springs and linear()

Springs feel natural because they overshoot and settle like real mass. The modern CSS linear() function approximates any curve — including spring bounce — by sampling points, so you get spring feel in plain CSS transitions (Chrome/Edge/FF/Safari 17.4+):

/* A gentle spring: tiny overshoot then settle — generate via tools like linear-easing-generator */
:root {
  --spring-bounce: linear(0, 0.006, 0.025, 0.101, 0.539, 0.826, 0.949, 1.001, 1.04, 1.011, 0.997, 1);
}
.chip { transition: transform var(--motion-base) var(--spring-bounce); }

Spring physics (Framer Motion / Motion / SwiftUI / Android) are tuned by stiffness (higher = faster, snappier), damping (higher = less bounce; critical damping = no overshoot), and mass (higher = more sluggish/heavy). Defaults that read well: stiffness 170–300, damping 20–30. Springs are duration-less — they settle when physics says so — which makes interruptible, gesture-driven motion feel right. Prefer springs for drag, drag-release, and anything the user can grab.

Micro-interactions

Anatomy (Dan Saffer): Trigger → Rules → Feedback → Loops/Modes. Trigger = what starts it (tap, hover, system event). Rules = what happens. Feedback = the visible/audible/haptic response. Loops/modes = what happens over time or on repeat.

The "1%" details: pressed states that depress, hover delays so tooltips don't flicker on pass-through, the loading button that morphs into a checkmark, the input border that eases instead of snapping. Users don't notice these individually — they notice their absence as "cheap."

Choreography & the animation principles

Multiple elements moving at once need orchestration, not chaos.

• Stagger — reveal list items in sequence, ~30–50ms apart, capped so a 50-item list doesn't take 2.5s (stagger first ~6, then snap the rest). Directs the eye and implies order.
• Sequence vs parallel — sequence when one thing causes another (sheet slides up, then its content fades in); parallel when things are peers. Don't sequence what could be parallel; it just feels slow.
• Follow-through & overlap — secondary elements settle slightly after the primary (the card lands, its shadow catches up a beat later). Springs do this for free.
• Anticipation — a tiny counter-move before the main move (a button dips 1px before launching a value) signals intent.
• Staging — animate the thing that matters; freeze the rest. If everything moves, nothing is emphasized.
• Secondary action — supporting motion (icon rotates as a panel expands) that reinforces without competing.

Map to Disney's 12: slow-in/slow-out = easing, follow-through/overlapping = stagger+spring settle, anticipation = pre-move, staging = focus, secondary action = supporting motion, timing = duration scale. These are the load-bearing five for UI.

Patterns (copy-paste)

Enter on insert with @starting-style (animate from display:none/popovers/dialogs — no JS):

.toast {
  transition: opacity var(--motion-base) var(--ease-out),
              transform var(--motion-base) var(--ease-out),
              overlay var(--motion-base) allow-discrete,
              display var(--motion-base) allow-discrete;
  opacity: 1; transform: translateY(0);
}
@starting-style { .toast { opacity: 0; transform: translateY(8px); } }
.toast[hidden] { opacity: 0; transform: translateY(8px); } /* exit */

View Transitions API (cross-document & SPA shared-element morphs):

@view-transition { navigation: auto; } /* same-origin MPA, opt-in */
.card { view-transition-name: hero; }  /* same name on both pages → morph */
::view-transition-old(hero), ::view-transition-new(hero) {
  animation-duration: var(--motion-slow); animation-timing-function: var(--ease-emphasized);
}

// SPA: wrap the DOM mutation; browser snapshots before/after and tweens.
if (document.startViewTransition) document.startViewTransition(() => updateDOM());
else updateDOM(); // graceful fallback

Scroll-driven reveal (runs on the compositor, no scroll listeners, no jank):

@keyframes reveal { from { opacity: 0; transform: translateY(24px); } to { opacity: 1; } }
.section {
  animation: reveal linear both;
  animation-timeline: view();          /* progresses as element crosses viewport */
  animation-range: entry 0% cover 35%;
}

FLIP for list add/remove/reorder — animate layout cheaply: measure First rect, apply Last (post-DOM) rect, Invert via transform to look unmoved, then Play by removing the transform with a transition. Animates transform only, never top/height. The Web Animations API or getBoundingClientRect() drives it; many libs (Motion's layout, AutoAnimate) wrap it.

Modal / sheet: backdrop fades (200ms), panel slides+scales from origin (scale(0.96)→1, translateY(12px)→0, 350ms ease-out). Exit reverses faster (200ms ease-in). Trap focus; animate transform/opacity, never width/height.

Loading: spinner if <1s expected & indeterminate; skeleton if you know the layout (shimmer 1.2–1.5s linear loop, low contrast); progress bar if measurable; optimistic UI if you can predict success — apply the change instantly, reconcile on response, animate a graceful revert on failure.

Number ticker: roll digits or interpolate value over ~400–800ms ease-out; respect reduced-motion by snapping. Parallax: subtle (background moves 10–30% of foreground), tasteful, and a top vestibular-trigger — gate behind reduced-motion.

Performance

Animate only transform and opacity. They run on the compositor thread — no layout, no paint, GPU-cheap, 60fps (16.7ms/frame budget) even under main-thread load.

• Replace width/height animations with transform: scale(). Replace top/left with translate(). Animate a shadow via an ::after pseudo whose opacity you fade.
• will-change: transform only just before an animation, remove after — it allocates a GPU layer and is a footgun if left on dozens of elements.
• Promote sparingly; thousands of layers thrash the GPU. Profile in DevTools Performance / Layers; watch for purple (layout) and green (paint) bars during animation — you want none.
• Jank causes: animating layout props, long main-thread tasks blocking frames, huge repaint regions, synchronous layout reads inside rAF, oversized images decoding mid-transition.

Accessibility — non-negotiable

prefers-reduced-motion is a real user setting (vestibular disorders, migraine, nausea, motion sickness). Honor it. Reduce, don't remove — keep instant opacity/color feedback so the UI still confirms actions; kill travel, parallax, spin, scale, and autoplay.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important; animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important; scroll-behavior: auto !important;
  }
}
/* Better: a deliberate reduced variant per component — cross-fade instead of slide. */
@media (prefers-reduced-motion: no-preference) { .panel { transition: transform var(--motion-base) var(--ease-out); } }

Rules: no information conveyed only by motion (pair with text/icon/color). Anything autoplaying/looping >5s must be pausable, stoppable, hideable (WCAG 2.2.2). Avoid flashes >3/sec (seizure risk). Don't trap users in a long unskippable transition. Test with the OS "Reduce Motion" toggle on.

Implementation toolkit

Platform: iOS — UIView.animate/UIViewPropertyAnimator (interruptible), SwiftUI withAnimation(.spring()), .interactiveSpring for gestures; system uses spring-by-default. Android — MotionLayout/ConstraintSet, SpringAnimation/DynamicAnimation, Compose animate*AsState/updateTransition; Material Motion patterns (container transform, shared axis, fade-through).

Cross-device: touch wants interruptible, finger-tracking motion (springs shine; gestures must reverse mid-flight); pointer can afford hover micro-interactions touch can't. Mind low-end devices — keep concurrent animations low, lean on the compositor, and let reduced-motion + lower frame budgets degrade gracefully.

Common mistakes (the do/don't)

Golden test: turn the animation off. If the UI is now confusing or feels broken, the motion was load-bearing — keep it. If nothing is lost, you were decorating — cut it.