Jan 10
7
Presenting Successful Demos
I was watching a presentation yesterday, half way through which the presenters fired up a demo of their application. To their horror, the demos failed spectacularly. After what seemed like an eternity trying to recover, the presenters were forced to move on, leaving the presenters visibly annoyed and the audience disappointed.
Although I’m not immune to this (I had an epic demo fail at JavaOne last year), in this post, I wanted to share a few things that I’ve found successful in preparing for and presenting technical demos.
All About State
I’ve lost count of how many demos I’ve seen that have failed on stage. One of the most common post-demo excuses is “That’s strange… it worked OK in my hotel room”. What these presenters don’t realize is that it’s all about state – and how two types of state changes can affect demos.
Predictable State. When you boot your machine, it starts in a particular state (let’s call it S1). When you test your demo in your hotel room, at the end of the demo your machine is in a different state (let’s call it S2). The demo was successful, and you assume that everything is going to be great for your talk. However, when you walk up to the podium, your machine is no longer in it’s original S1 state, it’s in S2 (because you’ve just run the demo previously). What many presenters fail to realize – until they have 250 people staring at them – is that the demo doesn’t work if the machine is in state S2. Maybe temporary files weren’t cleaned up, or the database connection was left open, etc.
Timeout State. Another case I see frequently is with time lag. I’ve also heard this referred to as “your machine being baked on stage”. In your hotel room, you boot your laptop (which is in state S1) and run the demo – and it works. What many presenters face however is a time lag between starting their talk and presenting their demo. For example, your machine could be sitting on stage for 50 minutes before you actually get to the part where you need to show your demo. By that time your machine is in a different state (maybe some kind of power saving / indexing / virus scanning has kicked in – or maybe your application has a memory leak / has closed database connection) and as a result fails.
How do you mitigate these two changes of state? There are a couple of things that I’ve found really help.
Firstly in your hotel room – either before the presentation or the night before – run the demo as you would, and then re-run it directly afterwards. At the time I’m often thinking “of course this is going to work”, but I’ve been amazed at how many times the demo actually fails on the 2nd attempt. For my more complex demos, one of the things that I’ve been considering is using some TDD approaches to help setup. For example, having a build script that will clean, compile, and run my demo together with a set of unit tests that will check the output. I can run this multiple times in the hotel room previously, and also again when I reach the podium before my talk begins.
Secondly, the only way to deal with the lag issue is to recreate the conditions that you’ll face. A full rehearsal in the hotel room the night before is often the only way to get around this. Many times I’ve been amazed to see that demos that normally need a few seconds to complete take much longer once the machine has been sitting there idle for half the presentation. There are a few things that I normally set by default to help mitigate this (e.g. ensure the machine is in high power mode, turn off unwanted settings etc.)
Scripts
To help recreate a successful state, for each demo I always use two scripts, in printed format. One is my “pre-req” script, another is my “run-through” script.
My pre-req script lists all of the things I need to do in order to get the demo in to a known state for presentation. This can include pre-opening the IDE, setting fonts correctly, minimizing windows, resetting config values, deleting output files, etc. I also have a master “pre-req” list that includes many things that I don’t need every time (switch off IM client, close Outlook, etc.)
My run-through script is exactly as it sounds – a script that I use during the presentation to run through the steps of the demo. I know many people feel uncomfortable reading from a script during a presentation – and for the slides, I completely agree – but for the demo, everyone in the audience tends to be looking at the screen and not at you directly, so while reading from a script might not feel natural, you’ll see that the audience won’t actually notice.
One thing I will say about the run-through script is that it needs to a set of mental prompts, not a set of instructions. For example, if the first part of your demo is to open a new browser window to your demo page, a mental reminder like this would work:
* IE –> http://myapp
Whereas this would not:
* Click on start, select Internet Explorer. Wait for browser to start. Go to address bar, enter demo address and click on OK.
In the heat of the moment, you won’t have time to process everything and you’ll end up ditching the script half way through.
Video Recording
You face your worst nightmare and your demo spectacularly fails. What’s your backup plan? For me, it’s a video recording of the demo produced the night before and made accessible before the presentation.
Many people dislike creating video recordings because they think the audience won’t like the format – or worry that it will take too much time to prepare. I disagree. The audience would prefer to see something in context of your presentation, even if it’s a recording. For example, let’s imagine that your demo doesn’t work during your presentation. It’s perfectly acceptable to spend a few seconds to try and recover before saying “Well, I seem to be having some trouble with the demo – let me switch to a recording instead and walk you through what I was going to show”. I open the video and within seconds the audience is able to keep context with the main flow of the presentation – and they’ll forgive me more for using a video than if they couldn’t see the original intended version.
In addition, if you are doing a full rehearsal the night before, it’s little effort to start some screen capturing software and record your demos. The video doesn’t have to be a Hollywood masterpiece – remember, this is for backup purposes only – and you don’t need to worry about audio (as you’ll be talking over the top of this).
When you record the videos, always set your machine to the resolution of the projector that you’ll be using (this is good advice for running through any demo prep). If you don’t know the resolution of the projector beforehand, I would recommend 1024×768. Your audience will prefer to see a demo with additional screen real estate vs. a demo that’s looks crammed because the resolution was too high.
After you’ve created the videos, I recommend copying a version of them to a folder on your desktop for quick access, and to either a USB stick or online storage where you can access them from another machine if need be. Many conferences that I’ve presented at often have a second presenter machine than I can use in case my demo machine dies.
As a final note, if all of this sounds way over the top, I like to remind myself of the time investment from the audience. If I have 100 people show up to a talk and I have a 15 minute demo, the audience is investing 25 man hours co
llectively just for that demo (100 people x 15 minutes). I feel that adding a few more minutes of my prep time to ensure the demo runs flawlessly is worth justifying the investment of everyone in the room.
