Tips for a Technical Presentation
I spoke at the local .NET user group meeting last week. I've done my share of software demos and short presentations to small groups, but this was the first time I've given an hour long technical talk to a large group. I'm making a list - partly for my future reference1- on some presentation tips while it's still fresh in my mind.
Scott Hanselman has several great posts about presentation tips, so that was the main place I looked to brush up.
Allow a lot of time to prepare
I've put together plenty of 15 minute presentations and had naively figured a one hour talk would take around four times as long to prepare. It may have been the subject matter, but putting together a full hour of content tool a lot more time. From what I've heard, the trend continues if you're going to be speaking for longer periods of time, so preparing a full day of training can take several days or weeks.
Pick demos for effect
I put some time into this, and I think in the future I'd put even more time into it. The demonstration is where everything comes together, where we see that it's worth learning something new because it wil help us do something cool (more on that later). So, early in your planning, make sure to think of how to make your demonstration exciting. I picked a rough topic for this, but I liked showing that (admitedly unsexy) tools like SMO and INFORMATION_SCHEMA allow you to build really cool stuff like Subsonic. In the future, I'll make this an even bigger part of the focus in my planning.
Set up a separate Windows account with large fonts and other presentation specific settings
This was probably the most important tip I took away from Scott's list. I set up a new Windows logon (I called my Presenter), then did the following:
- Put all the files or shortcuts I'd need on the desktop
- Set the font size to "Extra Large Fonts" (display options / Appearance / Font Size)
- Set the font size for all the applications I'd be using to 16 Point Consolas - pick what you want, but make sure it's big and readable
- Change any Visual Studio display settings
Set the screen resolution to something you're sure the LCD projector will support2
1024x768 is the best bet if you can't find out ahead of time. Learn from my example here - I forgot this step, and when I changed resolutions while testing before the meeting started, Windows required a reboot. I can't remember seeing that before, but I couldn't change the resolution without rebooting, which was a problem since I had a lot of demonstration applications running in debug mode. Fortunately I found that out before the meeting started, so I was able to set everything back up.
Test everything
I know that should go without saying, but it's important to test all sample applications, slides, etc. on the day of the demo. This is important, since things you've tested under your main login might not work under the new presentation user.
Have a Zoom tool ready and practice using it
Scott recommends Magnifixer. I think I prefer the shiny new ZoomIt tool from SysInternals since it includes some other goodies, like a Draw tool that lets you mark up the screen like a football comentator. I actually didn't end up using this since I was mostly showing off code, but I should have used it when demonstrating my winform applications.
Tell a story in three acts
A good presentation should clearly state the following:
- Problem
- Solution
- Result2
This is another Hanselman tip which I should have paid more attention. I thought I had some good structure to my slides, but I didn't do justice to the third act. I presented the background, some cool technologies (SMO and INFORMATION_SCHEMA), and finished by showing some exciting tools that leverage these technologies (most notably Subsonic). I think that made for a good story, but the ending needed a summary. Without that final conclusion slide (or portion of the presentation), it ended a little bit muddy. It's important to sum up what the presentation covered in a way that brings it all together.
Prestage but don't stack the deck
No one wants to see Visual Studio start up. We've seen that before. It's good to have things set up - solutions loaded, files you'll be showing open in tabs, etc. I didn't set bookmarks in my code, but I think I'll try that next time.
But... don't take it too far. There's a difference between prestaged and canned. Developers are used to seeing magical demos that don't really pan out when you try them at home, and their BS detectors start going off when you've got everything magically working due to to some sleight of hand. So, prestage things that are a waste of time, show things that might be tricky, and have an escape plan in case things go wrong. For instance, rather than setting up a Subsonic website beforehand, I demonstrated from a freshly unzipped SubSonic download folder. Subsonic is easy to set up - just a simple edit to the web.config file - but I thought that it was important to demonstrate that. If I had a more difficult edit to make, I'd prestage a file (named something like web.config.disaster) so I could attempt the edit on the fly, then if it didn't work I could delete the web.config and replace it with web.config.disaster.
Have a plan for your demos2
It's important to have a plan for what you want to show in your demo. Of course, you'll want a basic script in demonstrating the application, but you also want to have a script for how you want to explain the code. I think I'll try that bookmarking thing next time to see if that helps, probably with numbered bookmarks using DPack. The demonstrations are the payoff to the audience for sittng through all those slides, so it's important to get the most value out of them possible.
Have some backup material
I'm a "just in case" kind of person (nuclear power training kind of does that to you), so I had an extra slide and accompanying material which I didn't plan to have time to present. Sure enough, a simple database insert during one of the coolest parts of my final demo took a really long time, and it was nice to be able to say, "Hmm... Well, let's let that sort itself out for a bit and take a look at something else while we're waiting..." I'd want to be careful with that, so you don't confuse the audience by jumping around too much, but a little "by the way" sidebar kind of thing is nice to have in your back pocket.
Have a way to keep track of the time2
Scott included a speaker timer in the downloads from his Presentation Tips PPT post. It's pretty simple, but it shows the remaining time in the window title so you can minimize it and get a countdown display in the taskbar. I've been using TimeLeft recently and like it - it has a pretty nice timer feature that is pretty customizable, so you can make the time readable without being in the way. Neither of these are exactly what I'd want, but either will do the trick. Of course, you could just bring a stopwatch, but you'd look like a goof.
Practice
Make sure to run through everything (beginning to end) at least once, but preferably more.
Have fun
Go with it. Some things may bomb, just do your best. You're speaking to developers, and they know that computers delight in causing unexpected misery. They'll understand. Hopefully.
Extra Credit - Record it
I'd planned to have TimeSnapper and a voice recorder running during the presentation so I could review it later and perhaps turn it into a webcast. Unfortunately, I didn't start TimeSnapper after my forced reboot so I missed it. Camtasia might be better for this, but I'd be worried that it might get in the way of the presentation a bit too much.
What about you? Got any presenting tips presentation software suggestions?
UPDATE: Some great presenting tips from Lifehacker.
1 Hello, future Jon!
2 These are things I didn't do, but should have.