Step 8 · Motion and Three.js, sparingly

Because the deck is HTML, it can do things traditional slide tools can't: particles, 3D objects, background depth, spatial motion. Three.js covers that; animation libraries cover entrances, hovers, section changes, and emphasis.

The entire difficulty is knowing when not to.

One test

Motion has to make the presentation more memorable or easier to follow. It must not make the slides harder to read.

Same logic as the image test in step 6. The difference is that motion is easier to overdo, because building it is fun.

The prompt

Scan the deck and find where a restrained Three.js effect would help.
Use it only where it supports what the slide is saying.

Good uses:
1. A subtle animated background on the opening slide.
2. A 3D metaphor for one key concept.
3. Particles that add atmosphere without reducing readability.
4. A spatial visual that explains a system, a network, or a flow.

Constraints:
1. Not on every slide.
2. No visual clutter.
3. Text stays readable.
4. Performance stays reasonable.
5. The effect matches the deck's visual style.

Then tell me:
1. Which slides got effects.
2. What each one is.
3. Why it supports that slide.
4. Whether any of them should be removed for clarity.

Read the fourth answer carefully

"Whether any should be removed" gives it a way to argue against itself. In practice it will often name one or two — usually the ones that were already bothering you.

Style sets the budget

The official tutorial makes a genuinely useful call here:

• A busy deck takes less 3D. High saturation, high density, strong personality — the visual load is already full, and more motion is noise.
• A restrained deck takes a little well. Minimal styling has room for one quiet piece of movement, and the contrast makes it land.

Which is to say the motion budget runs inverse to the style. If you chose the bold direction, do less here than everyone else.

A concrete allowance

For a 10-to-15-slide deck:

Position	Allowance
Opening slide	One background effect is fine
Section breaks	One consistent transition treatment
Key concept slide	At most one slide deserves a 3D metaphor
Data slides	The chart's own entrance is enough; add nothing
Conclusion	Still. The last slide needs weight, not movement

One to three in total. Past that, what the audience remembers is the effects rather than the argument.

Performance is not a formality

Constraint 4 is real. A Three.js scene behaves very differently on a presenting laptop, through a projector, and over a screen share.

Test before you present:

• [ ] On the actual machine you'll present from
• [ ] Through the projector (the resolution changes; the particle count may not hold)
• [ ] Over a screen share, if it's remote — this is where it fails most often
• [ ] On battery (some machines throttle)

The screen-share case matters most. Particles that are smooth locally can turn to mush through video encoding.

The conservative alternative

When in doubt, use CSS animation instead of Three.js. Entrances, fades, translations — CSS handles all of it, performs predictably, and won't collapse in an unfamiliar environment.

OpenDesign also has an SVG + CSS motion skill that produces pure code, so it drops into a deck or a page and stays far cheaper than a 3D scene.

No Three.js on this slide. Use CSS for a restrained entrance: the
title first, then the three cards in sequence 120ms apart, ease-out.
It should not loop.

"It should not loop" earns its place. Continuous motion pulls attention the whole time you're talking.

Where it goes wrong

Trap	How it shows	Fix
3D on every slide	Motion sickness and a hot laptop	Cap it at one to three
Text over a moving background	Unreadable	Add a scrim, or move the text
Effects that never stop	The audience watches the background	Require them to play once and settle
Dropped frames on the projector	An awkward room	Test on the real machine and screen
A busy style with 3D on top	Visual overload	Apply the inverse rule and cut

Next

Step 9 · Comment, Mark, Edit — the structure holds; now close out the details.