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

Submitted by Robert MacLean on Wed, 01/20/2010 - 06:11

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

Today was a very busy day which started off with touching up the slide deck with a little more content and adding touches of animation to the slides. One thing I have learnt is that every time a change happens on screen, be it slide change or animation, the audience looks at that and since people can’t multi-task, 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 is no animations. Often on very wordy slides people will bring in the content, line by line so that 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 would rather have a 5sec pause between slides while people digest the new slide over ten 1sec pauses during the slide as they switch between me and the new text that just appeared courtesy of some animation.

image

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.

Clipboard01

Part of the demo script for one of the demo’s

Normally I do not need this guide, as I will have practised a the demo’s 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 demo’s 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 demo’s, this gives me my first chance to catch bugs and resolve issues in the demo’s before I get to my dry runs!
  5. Finally it also acts as a sounding board for the demo’s themselves. For example during creation of the script today, I took one demo and split it into two demo’s because it was just getting too much to do all at once.