Command Palette

Search for a command to run...

Hectal
Shots in this scene
SCENE 02Purpose and Principles
  1. 2.1The Five Jobs of Interface Motion
  2. 2.2When Not to Animate
  3. 2.3The Animation Principles for Interfaces
  4. 2.4Duration, Distance and Size
  5. 2.5Storyboarding and Motion Specs
  6. 2.6Build: The Launch Site Storyboard
← scene 01 · How Motion Works→ scene 03 · CSS Transitions in Depth▦ the storyboard
SHOT 2.2Beginner ~21 min · shot 2 of 6

When Not to Animate

In one line

The best animation is sometimes none. Skip motion for things people do many times a day, for anything started from the keyboard, and for anything that makes people wait. Tooltips are the classic exception: a delay the first time, instant after.

0/6 · 0%

Think of it like this

The first time you walk through a shop's automatic door, the slow glide is a small pleasure. The fortieth time, on a rainy day with shopping bags, you wish it would open at once. A motion's charm is spent on the first viewing, but its cost is paid on every one.

Words you'll meet

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

frequency
How often a person does an action. It decides how small the motion should be.
keyboard-initiated action
Something started by a key press, such as a shortcut. It should not wait for an animation.
grace window
A short time after a tooltip closes during which the next one opens at once.
command menu
A box opened by a shortcut where you type what you want to do, used many times a day.

Step by step

01Count the uses

Estimate how often one person does the action a day, and multiply by the duration. Near an hour a year is a red row.

02Check who starts it

If a shortcut or a keyboard focus starts it, run it with no animation. Give pointer-started actions the animation, if the other questions allow.

03Check that nothing waits for it

Focus, data and the next step must not depend on the animation ending. Focus the field and let the fade run on top.

04Decide: skip, shorten or keep

Skip for frequent or keyboard-started actions. Shorten frequent pointer-started ones (about 100 ms). Keep for rare, big or orienting changes.

Try it yourself

  1. 1

    Change the price

    In "The price of a wait", change the command menu's ms: 300 to ms: 100 and press Run. The first line now reads 80 x 100 ms = 8 s a day, 33.3 min a year, and the row is no longer red. A third of the time is saved by a shorter animation; all of it by none.

  2. 2

    See the delay on the timeline

    In the tooltip example, hover Reserve and keep still. The timeline shows nothing for 400 ms, then a transition · opacity track on div#tip, 120 ms long. Now press Tab to move to Cart: the tooltip changes at once and the timeline stays empty.

Code & diagrams

The price of a wait

Edit the numbers. The red row is one person's year, in minutes, spent waiting for a decoration. The last row has zero uses: nothing divides by zero, and the cost is 0.

Press Run to see the page.
00:00.000
animations
0.00s0.10s0.20s0.30s0.40s0.50s0.60s0.70s0.80s0.90s

Nothing is moving yet. Hover, click or scroll the page: every animation it starts shows up here as a track.

frames

Console

Nothing logged yet.

Expected console output

open the command menu: 80 x 300 ms = 24 s a day, 100.0 min a year
switch a tab: 200 x 200 ms = 40 s a day, 166.7 min a year
open a product dialog: 3 x 300 ms = 0.9 s a day, 3.8 min a year
see the welcome screen: 1 x 800 ms = 0.8 s a day, 3.3 min a year
an action nobody uses: 0 x 500 ms = 0 s a day, 0.0 min a year
A tooltip with a grace window

Hover Reserve and wait: nothing for 400 ms, then a 120 ms fade. Slide quickly to Cart: its tooltip is instant. Then Tab through the buttons: focus shows the tooltip with no animation at all (the timeline stays empty).

Press Run to see the page.
00:00.000
animations
0.00s0.10s0.20s0.30s0.40s0.50s0.60s0.70s0.80s0.90s

Nothing is moving yet. Hover, click or scroll the page: every animation it starts shows up here as a track.

frames

Console

Nothing logged yet.

Expected console output

first tooltip waits 400 ms; one opened within 300 ms of the last is instant
Feel itA command menu, with and without motion

Open the menu with the button, then with the K key, then close it with Esc. Do it ten times. Which one would you keep in an app you use all day?

A slides and fades in (350 ms)

Press Run to see the page.

B appears at once

Press Run to see the page.
Play both, then choose:

Break it on purpose

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

Break #1

Forget the grace window

In the tooltip example, delete the line warm = true; in hide(). Press Run, hover Reserve, wait for its tooltip, then move to Cart.

terminal
$ Move from one open tooltip to the next
── what you'll see ──
Cart's tooltip appears about 400 ms after you arrive, instead of at once.
Verified in a run: 100 ms after leaving Reserve, Cart's tooltip was still hidden, and its fade began only after the 400 ms delay.

Break #2

Let a tooltip that never opened start the grace window

In hide(), delete the line if (!visible) return;. Press Run, then sweep the pointer quickly across Reserve and onto Cart without stopping.

terminal
$ Sweep the pointer over two buttons
── what you'll see ──
Cart's tooltip appears at once, although you never rested on Reserve.
Verified: 160 ms into a sweep, opacity was already 1 with no transition; with the guard it stays 0 until 400 ms after arriving.

Myth vs fact

Myth

Animation always improves usability.

Fact

It helps when it does a job (Topic 2.1) and costs little. On frequent and keyboard-started actions it only adds a wait.

Myth

A tooltip should always have a delay.

Fact

Only the first one in a row. After that, and for keyboard focus, a delay is a delay.

Pro corner

Extra depth for experienced readers. New to this? Skip it for now and come back later.

  • ▸

    Skipping can be encoded, not just remembered: give a component an instant path (as the tooltip's transition: none class does) and choose it from the input type: keyboard focus, :focus-visible, or a shortcut handler. Reduced motion is one more reason to take that path (Phase 7).

  • ▸

    A grace window is a state machine with two timers: one to open, one to expire the "warm" state. Any timer you start needs clearing, which is why hide() calls clearTimeout first. A forgotten timer is a leak (Topic 8.1).

  • ▸

    This tooltip cannot be dismissed with Esc. WCAG 1.4.13 (Content on Hover or Focus, level AA) asks for tooltips that can be dismissed, hovered over without vanishing, and that stay until dismissed. Add an Esc handler before shipping.

Remember this

  1. 1

    The problem this solves: teams judge an animation on the first run, in a demo, when it looks wonderful. Real users see it hundreds of times. A 300 ms flourish on something people do all day turns into a tax. This topic gives you the questions that decide whether an animation should exist at all, before you decide how it looks.

  2. 2

    Question 1: how often? Do the sum, as the first example does. A command menu opened 80 times a day with a 300 ms animation is 24 seconds a day, about 100 minutes of one person's working year. Tab switching, 200 times at 200 ms, is about 167 minutes. A welcome screen seen once is 3.3 minutes in total. Frequent actions get no motion, or the smallest motion.

  3. 3

    Question 2: who started it? A person who presses a keyboard shortcut chose the keyboard to be fast. Making them watch a menu slide in works against that choice, so keyboard-started actions get no animation. Apple's Human Interface Guidelines agree: avoid motion on frequent interactions, and let people cancel motion rather than wait for it. Keyboard users still need feedback, but they get it from state (a highlight, a focus ring), not movement.

  4. 4

    Question 3: does it make anyone wait? An animation must never stand between a person and their result. Focus the input at once, apply the data at once, and let the animation play on top. If the next step cannot start until the animation ends, the motion is a delay. Product UI motion mostly stays under about 300 ms for this reason (Topic 2.4 gives the full table).

  5. 5

    The tooltip rule. Tooltips are the classic case of timing, not just yes or no. The first tooltip waits a short moment (the example uses 400 ms) so that sweeping the mouse across a toolbar does not flash tooltips. But once one has appeared, the next one, within a short window after the last closed (300 ms here), opens at once, because the person is clearly reading tooltips. A tooltip opened with the keyboard focus appears at once with no animation, because someone Tabbing through is not hovering.

  6. 6

    What still deserves motion. Things people see rarely or once (a welcome, a first-time tour), big changes of context where orientation helps (opening a page's drawer), and feedback so small it costs almost nothing. This is Emil Kowalski's "you don't need animations" argument; it is opinion, not measurement, so the arithmetic above is what you can defend in a review. Touch screens have no hover, so a hover-only tooltip needs a different trigger there (@media (hover: none)).

Explain it without notes

01

A command menu is opened 80 times a day. Should it animate? Argue with numbers.

02

Describe how a well-behaved tooltip decides when to appear.

03

Why should keyboard-started actions not be animated, and what do keyboard users get instead?

Practice

01

Add one more row to the first example for an action in your own app. Is it red? What would you change: the duration, or removing the motion?

02

Make the command menu in the feel pair open instantly with the K key but animate (150 ms) when opened with the button.

Done when you can

  • You can do the frequency sum and say when an animation costs too much

  • You know why keyboard-started actions should not animate

  • You can describe the tooltip's delay, grace window and keyboard rule

  • You can say what still deserves motion