Presenting the Internet
I’ve been giving a number of talks recently at conferences like the Adobe Internet Solutions Conference, and I thought I’d share some of the tricks and techniques that I’ve worked up for Internet presentations.
While I was a student at Cornell, my part time job involved managing a seminar room with a projector. I’ve seen (and rescued) far too many demonstrations undermined by technical glitches. As a result, I tend toward extremely low-tech presentations. Short of laryngitis, there’s not much that can go wrong if you’re just talking. Add an overhead projector and the bulb could blow; use a Macintosh and the projector can mess things up in any number of ways, not to mention all the potential problems of using an unfamiliar Mac with unexpected fonts and extensions. Add a live Internet connection and you’re tempting the laws of Murphy (whatever can go wrong, will).
So, my main advice for any presentation is to keep the level of technology involved to a minimum. Obviously, since we’re talking about Internet presentations, that’s difficult, so the corollary is that when you must do a high-tech presentation, isolate and eliminate as many variables as possible. If you have your own PowerBook and can connect to the projector, use your PowerBook rather than whatever Macintosh might already be there. If you have your own modem, ditto. Anything you can do to stick with a known, working situation rather than venturing into the unknown reduces your chances of blowing the presentation.
For Internet presentations these days, I’ve had extremely good luck with doing my "slides" in HTML rather than in a program like Persuasion or PowerPoint. Aside from the fact that I don’t use either of those programs, HTML is extremely flexible. For instance, I can put my presentation up on my Web server as a backup in case something happens to the copy I bring with me. I’ve never needed that backup, but making slides in HTML also simplifies showing off a variety of Web sites as part of the presentation – just click and you’re there. I’ve made HTML slides for presentations a few times now, and they tend to be extremely simple. Each slide usually contains a small graphic at the top and then a short list of points. The slide finishes with Next and Previous links for moving around. You can make links all over in your presentation, but I recommend keeping it mostly linear because it’s too easy to become flustered while you’re on stage.
The way I create my slides is a little unusual. Working from an outline, I go straight through the talk, creating the HTML file for each slide as I go. I name the first file something like "connect1.html" and when I’m done with that one, I duplicate it in the Finder, rename it to "connect2.html" and edit it, which is easier and more consistent than trying to do each one from scratch. Get the first one right, or else you’ll have to make changes in all the files after that point. Small changes aren’t a problem if you use a tool like BBEdit or NisusWriter that can find and replace across all the files in a presentation. I’ve seen other HTML slide presentations done as a single long HTML document, which you can either scroll through or use internal anchor links.
If you plan to show examples of Web sites during your presentation, consider using WebWhacker from The ForeFront Group to download some of the site, complete with graphics and internal links. That way, if your Internet connection isn’t working when you give the presentation, it won’t matter. It’s often a good idea to make two links for each sample site, a local one to the downloaded version of the site and a remote one to the online version of the site, because there are times that you might not have downloaded the part of the site you need. More importantly, sometimes it’s good to show the real speed of the site, rather than the speedy canned demonstration from your hard disk.
Another reason to use HTML for your presentation is that it provides a variety of options for which browser you use. Unless you present sites that rely on Netscape extensions, for instance, it doesn’t matter all that much. Tonya likes using MacWeb because it provides much more control over onscreen fonts and styles than Internet Explorer or Netscape Navigator. Speaking of fonts, when you test your HTML at the site of the presentation with the projector on, make sure the font you use is readable from the back of the room. Netscape, for instance, defaults to using Times 12 point for its text font, which is small and hard to read onscreen. I usually switch to New York 12 point, which is easier on the eyes and designed for onscreen readability. If you use separate HTML files for each slide, run through your entire presentation to ensure you’ll have a minimum of scrolling – scrolling distracts you from the task at hand, which is speaking.
No matter what, shut off as many of the toolbars and other fields at the top of the window as you can. No one will be able to read the Location field, and if your presentation is local, the URLs will be useless anyway. Things like Netscape’s Directory Buttons are pointless for the purposes of the presentation, and take up screen space your slides could use to avoid scrolling. Also, many people in your audience may not be able to see the bottom third of the screen, so you’ll want your information to be up at the top where everyone can see it. This may seem like a minor point, but you don’t want to waste screen space or distract your audience with unnecessary screen controls, and few presenters seem to realize this.
Since no one can see the URLs for the sites you visit, make sure to include them on a handout for the audience. It’s a good idea to provide a handout anyway, since that keeps people from madly taking notes when they should be paying attention to what you’re saying. For some reason, audiences are always desperate to know exactly what URLs you’ve visited, and URLs are deucedly hard to convey in spoken words.
I don’t want to get into the details of actually making the presentation, other than two quick points. First, if you only have a modem connection, don’t apologize for its speed, or, if you must, only apologize once. Second, when you take questions from the audience (which you definitely should do, but only at appropriate breakpoints and again at the end), make sure to repeat the question before answering it. Failing to repeat the question so everyone can hear it before you answer is probably the most common failing of technical presentations.