How to Add Animation to Slides

Classic slide software treats animation as a fixed catalog: Fade, Wipe, Fly In, pick one and apply it to the whole object. It works, but it is limited to whatever effects the software shipped with, and every deck built with it tends to move the same way.

An Eazy slide is different at the foundation. It renders as a real web page, meaning the title, the bullet list, the chart, and the image are actual HTML elements that CSS can animate. When you ask Eazy's AI to "fade the headline in from the left," it is not selecting a preset, it is writing a CSS transition or keyframe animation targeted at that specific element.

The practical difference shows up the moment you want something a preset menu does not offer. "Stagger these three bullets in with a slight delay between each" or "make this stat count up when the slide loads" are not built-in transitions anywhere, but they are ordinary CSS, and ordinary CSS is exactly what a coding agent can write when you ask.

1. Pick the slide, not the whole deck. Animation requests are one-slide edits. Open the specific slide you want to move, since "animate this deck" is too vague for the AI to act on precisely.

2. Name the element and the effect in plain words. "Fade the title in," "slide this image in from the right," "make these bullets appear one at a time" all give the AI a clear target and a clear motion. You do not need CSS vocabulary like "ease-in-out" or "transform: translateX" — describe what you see happening.

3. Add timing or sequence if it matters. "Wait half a second before the subtitle appears" or "stagger the three cards left to right" turns a single animation into a sequence. The AI translates that into animation-delay and keyframe timing on its own.

4. Preview it live and iterate. Because only the slide you referenced rebuilds, you can watch the motion, then ask for a tweak, "make that faster," "less bounce," "delay it a bit longer", without touching the rest of the deck or losing the slides you already like.

Entrance animations are the most common request: a title that fades or slides in, an image that scales up slightly as it appears, a stat that counts from zero. They set the pace of a slide the moment it comes on screen, which matters most on an opening or section-break slide.

Staggered reveals apply the same idea to a group: three bullets, four cards, or a row of logos, each appearing a beat after the last instead of all at once. This is useful when you want an audience reading along with you rather than reading ahead of the point you are making.

Hover effects respond to a cursor rather than to the slide loading, a card that lifts slightly, a button that changes color, an image that reveals a caption. They are naturally suited to a shared web deck someone is exploring on their own, since a hover state has nothing to respond to on a printed page.

Transitions smooth a change of state rather than an entrance: a tab switching content, a value updating, a chart element highlighting on interaction. They read as polish because the change looks intentional instead of abrupt, and they cost nothing extra to ask for since they are the same kind of CSS as the other three.

The easiest animation mistake is applying it everywhere out of enthusiasm rather than purpose. A slide where the title, the bullets, the image, and the chart all animate in separately at once reads as busy, not polished, and it slows down the moment your audience actually needs to start reading.

A better default is one animation per slide doing one job: bring in the headline first so eyes land there, or stagger three points so the audience reads them in the order you intend. If nothing on the slide needs sequencing or emphasis, it is fine to leave it static. Not every slide needs to move.

Speed matters as much as choice of effect. Ask for animation that is quick and subtle, most entrance effects read best well under a second, rather than a long, showy motion that makes the audience wait to read the point. If a first attempt feels slow or distracting, "make that faster" or "tone that down" is a normal follow-up request, and only that slide rebuilds.

This is a rendering fact, not a limitation specific to Eazy: a PDF page or a PowerPoint slide is a static image, and a static image cannot run CSS. The moment you export, the browser that was animating the slide is no longer in the picture.

The practical implication is to treat the shared web link as the presentation, and the export as the artifact you leave behind. If you are presenting live or sending a link for someone to explore on their own screen, the animation, hover effects, and interactive charts show up exactly as built. If you need a PDF for an email attachment or a PPTX for a printed handout, expect the polished, still, on-brand version of the same slide, not the moving one.

Nothing about this boundary touches what animation can do inside the live deck. It only means the choice of when to send a link versus when to export a file should account for whether the motion is part of the point you are making.

Once a title fades in or a card lifts on hover, the natural next question is what else the slide can do. Because the underlying mechanism is the same, real code written by an AI editing real HTML, the answer extends well past animation: ask for an in-slide tab set, a card carousel, an expandable reveal, or navigation that responds to a swipe on a phone.

The rule of thumb stays consistent across all of it: if the behavior lives inside the slide and runs in the viewer's browser, it is fair game to ask for. If it would need a form submission, a login, a link that opens a new page, or a connection to live external data, it is outside what an in-slide, client-side deck can honestly do.