How to Add Motion and Behavior to Slides

Most presentation tools give you a canvas: shapes and text positioned on a flat rectangle, flattened to an image or a fixed layout the moment you export or present. There is no code underneath to change, so "add a behavior" is not really a request that means anything — you are stuck with whatever preset transition the software ships with.

An Eazy deck is different at the foundation. Every slide is a live web page — real HTML for structure, CSS for style and motion, JavaScript for behavior. When you ask Eazy's AI to change something on a slide, it is not repositioning a shape on a canvas; it is editing the underlying code, the same way a developer would. That is what makes motion and behavior possible at all, and it is why the range of what you can ask for is wide rather than a fixed menu of "transition styles."

You do not write any of that code yourself. You describe the outcome in plain language — "make this chart draw itself in when the slide appears," "make this card flip to show the back on hover" — and the AI translates that into working CSS and JavaScript on that one slide. It is the same conversational editing you would use to fix a sentence or resize an image, just aimed at motion and behavior instead of content.

1. "Make this chart animate on entrance." Bars grow from zero, a line draws itself across the axis, or pie wedges sweep in as the slide comes into view, instead of the whole chart just appearing at once.

2. "Make these cards flip on hover." A stat card, a team bio, or a feature tile flips to reveal a back face when the cursor lands on it — useful for packing a comparison or a definition behind a headline.

3. "Make this number count up." A big metric on a stat slide animates from zero to its final value as the slide appears, which reads as more alive than a number that is simply printed on the page.

4. "Reveal this list step by step." Instead of dumping five bullets on screen at once, each item fades or slides in on its own beat, or waits for a click, so the audience reads with you rather than ahead of you.

5. "Make this diagram respond to hover." Hovering a node in a flow diagram or org chart highlights its connected paths and dims the rest, so a dense diagram becomes easier to read one relationship at a time.

6. "Give every element on this slide a subtle entrance." Headline, image, and bullets each animate in with a slight stagger and delay, instead of the whole slide popping into existence as one flat block.

7. "Turn this into tabs." Three blocks of content that would otherwise crowd one slide collapse into an in-slide tab switcher, so a viewer clicks between them without leaving the slide.

8. "Make this image carousel swipeable on mobile." A row of screenshots or photos becomes swipe-navigable on a phone, and click- or arrow-navigable on desktop.

9. "Make this progress bar or timeline fill in as the slide loads." A roadmap, a funnel, or a progress indicator animates its fill rather than sitting there fully drawn from the first frame.

These are examples, not a fixed menu. Because the AI is editing real code rather than picking from a preset list, the honest framing is that imagination is the limit for what you can ask an element on a slide to do — as long as it stays in-slide and client-side, which is the boundary covered below.

The flow starts wherever you already are: looking at a slide in the editor. You open the chat and describe what you want, naming the element ("the bar chart," "this three-column layout," "the headline") and the behavior ("animate the bars in from zero," "make the columns flip on hover"). Being specific about which element and what the trigger is — page load, hover, click, scroll into view — gets you a closer result on the first try.

Because the request targets one slide, only that slide rebuilds. The rest of the deck, and the rest of that slide's content, is left alone. This is the same surgical, one-slide-at-a-time editing that Eazy uses for content changes, applied to motion and behavior instead of wording — change one line, or one request, and it does not ripple the whole presentation.

You see the result live in the deck, so you can judge whether the animation reads right, the hover trigger feels natural, or the reveal pace is too fast. If it is not quite right, you ask again — "slower," "trigger on click instead of hover," "keep the flip but drop the shadow" — and the AI adjusts the same slide. This iterative loop is the same conversational editing used everywhere else in Eazy, just applied to how a slide moves and reacts rather than what it says.

The honest boundary matters as much as the wide range of what is possible. A slide can animate, react to a hover, count up, and reveal in steps, all inside itself. What it will not become is a small application: no login forms, no data-entry fields that submit anywhere, no links that navigate to another page or open a new tab, and no pulling in live external data from an API or a spreadsheet. If a request would turn the slide into an app rather than a slide that behaves, it is out of scope.

The second boundary is where the behavior lives. Everything described here is live-render — it works when someone is viewing the deck through its shareable web link, in the browser, where the real HTML, CSS, and JavaScript execute. The moment you export to PDF, PPTX, or PNG, that slide becomes a static image or a fixed document page. The chart that hovered with tooltips renders as a plain picture of a chart; the card that flipped renders in whichever state it was captured in. Motion and interactivity are a property of the live deck, not of the exported file.

In practice this means you choose your distribution method with that trade-off in mind. Share the live link when you want the animated, reactive version people can hover and click through. Export to PDF or PPTX when you need a static file for printing, emailing, or archiving, and expect it to look like a well-designed, still snapshot of that same slide.

A useful test before you ask for a behavior: does this help someone understand the slide faster, or does it just look busy? A chart that reveals one series at a time while you talk through each one is doing real work — it paces the audience through data instead of dumping it all at once. A headline that pulses, bounces, and spins for no reason competes with itself for attention and slows down a reader who just wants the words.

A good pattern is to spend motion on the one or two elements per slide that carry the point — the key stat, the pivotal chart, the diagram you are about to explain — and leave supporting text and layout calm. Reserve hover reveals for detail that would otherwise clutter the slide: a definition behind a term, a breakdown behind a summary number, a back-of-card note that would be too much text if it were always visible.

If you are not sure whether a request is worth making, picture the slide with the animation stripped out. If it would still communicate its point clearly, the motion is a nice-to-have you can add for polish. If the animation is doing work the static slide could not — pacing a reveal, showing a relationship on hover, drawing attention to a change — it is worth asking for.

The clearer the request, the closer the first result. Instead of "make this slide more interesting," name the element ("the revenue chart," "the second row of cards") and the behavior you want ("animate the bars up from the baseline," "flip to show the label on hover"). If the trigger matters — should it happen automatically when the slide appears, or only on hover, click, or scroll — say so, since that is one of the first things an ambiguous request gets wrong.

It also helps to ask for one behavior at a time rather than redesigning the whole slide's motion in a single message. Get the chart entrance right, look at it, then move to the cards. This mirrors how the surgical, one-slide rebuild already works for content edits: small, specific asks produce results you can evaluate immediately, and you refine from there rather than guessing at a big combined request.

Plain-language pacing words work better than technical ones. "Slower," "reveal one item at a time," "wait for a click instead of firing automatically," and "keep it subtle" all land, because you are describing the feel you want rather than trying to specify an easing curve or a duration. Describe it the way you would explain the effect to a colleague watching over your shoulder, and let the AI handle the implementation.