When you demo ...
Here are some things to remember:
- Be comfortable.
Unless you have an unusually high table, sit down. Computers have been designed to be used while sitting down. If you stand up several things happen: you are uncomfortable and you look awkward as you need to bend to manipulate the computer. You will probably need to use the mouse. If you do, make sure you have enough place to use it. Move the table so that you can easily face the audience. Also, make sure you can easily move to and from the table (for example, no stretched cable requires you to jump over it to reach the table) - Every so often check if the projected screen shows what you want.
Demoing is all about showing, and you need to ensure that the audience sees what you want them to see. - Look at the computer screen and not at the projected screen.
After checking what the projection shows, you will have the tendency to continue looking at the projected screen and try to manipulate the computer like that. This will make you slow and again you will look rather odd. When you manipulate the computer always use the computer screen. - Never point to the computer screen.
While working on the computer, you will have the tendency to point with your hand to the computer screen. Obviously, the audience cannot see what you are pointing at. Either use the mouse to show the area, or point to the projected screen. To make the mouse a more effective pointing device, I learnt from Adrian Kuhn to make the mouse pointer extremely large (on Mac you can do that from Universal Access settings). Another trick I learnt from Thomas Zimmermann is to use mouse enhancers like Mousepose or OmniDazzle. - Make contact with the audience.
Demoing is after all about talking with the audience. When you sit at the computer you have the tendency to look only at the screen, and if you do that you lose the feedback and the audience might lose interest. - Speak loud.
When you are looking at the screen you will have the tendency to speak softer because you will perceive the space as smaller. One trick I use is to stand up when I have to speak for more than 30 seconds. In any case, even if I do not stand up, I release the mouse and the keyboard just to make my brain enter the speak-loud-to-the-audience mode. - Describe what you do.
Clicks are hardly detectable: they are invisible and in a large room clicks sound cannot be heard. The same goes for shortcut keys. As a consequence, you have to describe the actions you are taking. For example you can say something like: "if I click on the ... (click) then ... (and something happens)." - Describe what we see before you tell how it should be interpreted.
Because you already know what your application is doing and how it looks like, you will be tempted to only describe the value of the application. However, for the audience it might not be clear what is shown. Thus, you need to take your time and first describe what the audience sees, and only afterwards talk about the value. For example, you can say: "In this window you see ... (this is the descriptive uninteresting part) and what this shows is ... (and only here is the interesting part). - Have power.
Ok, this one is a requirement for presentations in general, but demoes tend to consume more power than just showing slides, especially if they require a lot of computation. So, even if you think you have enough battery in your laptop, make sure it is hooked up. - Switch off the screen saver and the sleep mode.
This is yet another basic generic requirement for presentations. Still, it happens too often that speakers forget to turn off the screen saver. So, please, remember next time to switch off your nice screen saver. - Close all unnecessary applications.
Nothing is more annoying than a mail announcement or a chat window popping out while doing a demo. It distracts and spoils the flow. So, close all applications except for those needed for the demo. - Have backup slides.
Backup slides have two purposes. On the one hand, they serve as material you can use to make your point in case the demo does not work. On the other hand, you can use them to summarize what the demo is about. - Know your demo, but have a step-by-step script ready.
There is no replacement for rehearsal, but even if you know your demo backwards, having the script close by will reduce the stress. For example, this is how the notes of Steve Jobs looked like for the iPhone demo. - Have your demo short.
The longer the demo, the less the impact and the more the chance for a bug to appear. So, keep it short. - Have the starting point prepared.
A demo is about impact and you should focus on what makes that impact. Thus, eliminate all the preparation steps up to what is interesting and have the starting point prepared before the demo. For example, most of the time starting up the application is not the most interesting thing, especially if it takes time. In such cases, you are better off by having your application started before the demo. - Have a story if the computation is expected to take long.
It happens that some parts of your demo require a longer computation time. If they are just preparation steps you can always pre-compute them. If that is not the case, one trick for getting around computations is to tweak your application and have the results hardcoded just for the demo (of course, as you do not want to deceive the audience, you have to explicitly say that the computation was cached for demo purposes). But if there is no way to go around these long computations, have a story prepared to avoid the awkward silence. There are many things you can do: use the time to explain in detail what is going on, have the audience ask questions, or continue with the rest of the presentation and get back to the result later on. - Try at maximum two times when something goes wrong.
Why two times? Because once can be just a mistake from your part and you might notice it the second time. But if it goes wrong the second time, no matter what the problem is, you will most probably just continue doing the same thing over and over. If it does not work you are better off just moving on. If possible make fun of yourself. For example, you can say something like: "this is why they are called prototypes." - Test the beamer before the presentation.
Check the resolution of the beamer beforehand, and resize your windows to fit the screen. There is nothing more annoying that not being able to see or manipulate your application. - Switch, don’t end the slide show.
When switching between slides and the demo, many times presenters just press Esc to end the slide show, switch to the application, and then restart the show. This results in a rather clumsy situation. A much better solution is to hide or to switch to the other application from the slide show. On Mac you can always use the Apple+H button to hide any application (I got this tip from Oscar Nierstrasz). In Keynote you can also use simply the ’H’ button. This will make the slides fade away and make room for what is behind. Thus, you can just open the slides on top of the your application, and the transition will be smooth. When you are done, just click on the Keynote or PowerPoint icon (or switch with ALT+TAB or Apple+TAB). On Windows, the best way I could find is to switch to the other applications using ALT+TAB. - Fight for your machine.
If you are requested to demo on a foreign computer, argue that you want to use your machine. In most cases it will work. If it really does not, make sure you take your time to test the new computer.