Presentation Patterns: Demonstrations Versus Presentations
This chapter is from the book
This chapter is from the book
This chapter is from the book
Although presentations frequently include demonstrations, presentations and demonstrations are not the same thing. A demonstration is designed to show directly how something—generally either a tool or a technique—works. A presentation presents information about something; the something could be a tool or technique that you discuss with or without demonstrating it. The patterns and anti-patterns in this chapter clarify this subtle but important (and often missed) distinction.
It is common to build a presentation around the output of a tool such as spreadsheet software or a programmer’s integrated development environment. Although you can embed the output directly into the presentation, we show several better patterns (Traveling Highlights, Crawling Code, and Emergence) that add veracity and remove risk.
Pattern: Live Demo
Also Known As
Live Tool Use, Live Coding
Definition
You demonstrate in real time how something works or how to do something as part of your presentation. Successful implementation of this pattern can turn a demonstration into performance art.
Motivation
The motivation for demonstrating something within a presentation varies widely. At its most noble, it shows the audience members something they want to know in an interesting, entertaining context. Perhaps it seems like less work to throw together a few Bullet-Riddled Corpse introduction slides and then demonstrate the tool or technique in an ad hoc way. At its worst, it boosts the presenter’s ego while lacking information quality and density. We identify this as a dangerous pattern to be used by advanced presenters only. We’ve seen many presenters who think they are delivering a great demonstration but are actually just annoyingly stroking their own egos.
Live Demo can be a life saver if you don’t have enough material to make a compelling presentation in the time you have. Interacting with a tool is a great time sink and—if done to encourage audience interactivity—a benefit to the audience as well. (But see the Dead Demo antipattern for the dark side of this motivation.)
Applicability/Consequences
Live Demo works particularly well when the following occurs:
- The presentation consists of instructional material about a tool or technique.
- The topic is completely new to the audience, and you want to start from a known context to lead them toward new ideas.
- The focus of the talk is the interaction with the tool or application of the technique.
- The technique is something the attendee is expected to mimic, in whole or in part, either in real time or later.
This is an effective pattern when the focus of the demonstration is a tool or technique. It becomes the Dead Demo antipattern when that’s not the case. It’s extremely difficult to perform well—and trivially easy to do so poorly that the audience checks out completely. Performing a Live Demo well takes an enormous amount of practice (see Carnegie Hall pattern), deep knowledge of the subject, bravery, and calm in the face of the unexpected—along with the ability to speak in well-considered, articulate sentences while performing a complex and error-prone task in front of a large group of people. You might want to consider the Lipsync pattern instead.
When performing some intricate technical feat such as writing source code, you’ll make mistakes, no matter how well you’ve practiced. One of the benefits of live demonstrations is the contextualization for the audience members: they empathize when something goes wrong. It makes the presenter more human and provides the opportunity to discuss important tangents. However, the worst part of this pattern also manifests in this situation: it can destroy or at least seriously harm the presenter’s reputation if an unrecoverable error or mistake occurs.
Mechanics
You must be effective in ad-libbing with the tool you are demonstrating (with). The most difficult aspect of this pattern is the immense level of audience concentration the presenter must maintain. It’s boring to watch someone use a tool and excruciating to watch someone backspace over mistakes repeatedly, so most presenters keep lively banter going at the same time. That’s hard enough to do when things go well and extremely difficult when unexpected variations arise.
Make sure you have a firm agenda. It’s OK to stray from it at the audience’s request, which is one of the benefits of this approach, but you don’t want to be seen as fumbling around. Make sure you have goals in mind and keep on track. Be willing to say no to audience requests if you think they’ll provide a poor Live Demo experience.
Practice is essential. By demonstrating something in front of a group, you are an expert on it, no matter how much you might disclaim otherwise (which never helps—see the Going Meta antipattern). You must look polished in your demonstration and should be able to answer questions as you go. Your knowledge must significantly exceed that of others in the room so that you can answer questions gracefully.
One way to reduce risk if you do undertake a Live Demo is to create intermediate versions or snapshots beforehand of what you’ll be demonstrating live. If something goes terribly wrong, you have a known good place to restart and hopefully regain your composure.
If you do want to show the audience the mechanics of something via a Live Demo yet don’t want to incur the ongoing risks, you can start the presentation with a few Live Demo examples then switch to a safer pattern like Lipsync.
Known Uses
Nikon, on the release of its D4 DSLR camera, had a situation in which it was imperative to give a live demo.1 To prove that an innovative remote-control feature was already in the camera hardware (not an implementation of the Lipsync pattern), the presenter turned the camera on the audience members and displayed live pictures of them. The presentation gave credibility to the feature and assuaged any of the audience’s concerns that it was technological vaporware.
)
Figure 5.1. The Nikon D4 live demonstration
In 1994, Bill Gates decided to do a live demo of Windows 95 and its Plug and Play capabilities. He performed a move that had likely been practiced dozens of time—connecting a scanner—and snap, the dreaded “blue screen of death” appeared.2 Gates tried to deal with the situation as well as possible, but the audience lost its focus on the talk’s real goals and laughed hysterically. The snafu made the news on many local TV stations around the world—not exactly what Gates was hoping for.
Related Patterns
The Dead Demo antipattern is the evil twin of Live Demo.
The Lipsync pattern is a common way to replace a Dead Demo with a presentation.