How I Build Presentations, day 5: Animation and Demo Script

Published on 20 January 2010 • Estimated reading time: 2 minutes

For the rest in the posts in this series, please see the series index.

Today was a very busy day, which started with touching up the slide deck—a little more content and adding touches of animation to the slides. One thing I’ve learnt is that every time a change happens on screen—be it a slide change or animation—the audience looks at that, and since people can’t multitask, they stop listening to you. So while animations and transitions may look flashy, they must be used with care—or you risk having long pauses or the audience ignoring you.

For this presentation, there are a few slides where I want to take the audience step by step through a process as I narrate it to them. However, for the rest of the slides, there are no animations. Often, on very wordy slides, people will bring in the content line by line so the audience doesn’t get ahead of the speaker. For me, I have text—I dump the entire text on the screen at once, which may seem odd since everyone will start reading it. However, I’d rather have a 5-second pause between slides while people digest the new slide than ten 1-second pauses during the slide as they switch between me and the new text that just appeared courtesy of some animation.

Slide deck at the end of day 5

The next stage is to get my demo script written. To do this, I take the demo shell and step by step write out exactly what should occur.

Part of the demo script for one of the demos

Normally, I do not need this guide, as I will have practised the demos a few times and will have it almost memorised. But it is worth creating for five reasons:

1. If I need to present in the future, I do not need to try and remember what I did. I just read the script, practise, and I am ready to go.
2. When I hand out the presentation, people who look over it can read the script and recreate the demos themselves if they choose.
3. I use a tool to help me with my text (which I will discuss in a future blog post), but if something goes wrong with that tool, then the code I need is backed up in the demo script.
4. In preparing the script, I need to run through my demos, which gives me my first chance to catch bugs and resolve issues in the demos before I get to my dry runs!
5. Finally, it also acts as a sounding board for the demos themselves. For example, during creation of the script today, I took one demo and split it into two demos because it was just getting too much to do all at once.