How Bad Presentations Led Me to Create Presentation Patterns
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
My first speaking experience at a technical conference was in 1997 at the Borland Developers Conference (BorCon) in Nashville, Tennessee. Despite teaching lots of technical training courses as part of my day job, speaking in a formal setting was nerve-racking, and my performance was abysmal due to lack of experience. I had no illusions that I knew what I was doing.
But I kept doing it, and gradually I got better. By 2004, I had spoken at approximately 25 conferences, and I felt like I had a pretty good handle on the content of the presentation. Like many technical presenters, I paid little attention to the slides, which traditionally were thrown together at the last minute.
Slides at technical conferences were viewed as a necessary evil. Most presentations heavily featured demonstrations of technical prowess, illustrating points using developer's tools. The tradition was to get all the examples working, and then spend a hour banging out an outline using slides to serve as a guide through the topic. These slides were as much for the speaker as for the audience, as a reminder of what to talk about next. Occasionally, if I were feeling ambitious, I might include a diagram or other visual aid, but my slides were almost exclusively Bullet-Riddled Corpses, laden with Floodmarks for both my company and the conference.
NoteThen three things happened that changed my presenting style forever and led me to collaborate on Presentation Patterns: Techniques for Crafting Better Presentations.
The book's companion website includes a glossary of all our patterns and antipatterns, as well as a blog and extended discussions about pattern-related topics.
Dead Demos
One of the seminal events in my speaking career was my introduction to the No Fluff, Just Stuff conference series, which happened when my publisher at the time introduced me to the organizer, Jay Zimmerman. When I started on the No Fluff, Just Stuff tour, my slide style had evolved very little. I had prettier backgrounds, and I had started thinking at least a little about the visual aspect, but I was still in "technical presenter" mode: Show a few slides as introduction, quickly bounce over to the tool(s) that illustrated technical points, and spend most of my time interacting with the tool live. Every once in a while, I would bounce back over to the slides to make sure that I had covered all the topics they promised, advancing a few slides to get to the next main point, and then heading off to the tools again. My slides circa 2004 looked like Figure 1, which is a slide from my presentation "Power Regular Expressions in Java."
)
Figure 1 A 2004 slide, filled with what I would now call Floodmarks.
Like many technical presenters, I felt the need to show examples in the tools that created them—note the "Example" bullet point in Figure 1, which was my signal to bounce over to a software development tool to show an example.
Mostly I was showing computer source code, which is plain text, but I felt compelled to show it in the tool that created it. I was also careful to execute the code after I talked about it, by way of proving that what I was showing actually worked. As the tools and techniques I was presenting became more complex and nuanced, so did the demonstrations I was performing live.
The ultimate expression of this style of presenting was a presentation named "Advanced Selenium," about a testing tool named Selenium. To demonstrate the tool, I needed no less than five applications running, using several browsers, bouncing back and forth between the applications to show various aspects. From a technical standpoint, the talk was a tour de force, illustrating some mind-blowing techniques and general coolness to the audience. I viewed the proliferation of applications and views as a bonus, giving the audience deep insight into what was going on. But all the bravado with tools was really just an ego boost to me, to show how proficient I was at dealing with complex tools and concepts.
One of the killer features of the No Fluff, Just Stuff conference is the excellent feedback form, which the attendees always filled out in great detail. One of the feedback forms from my "Advanced Selenium" talk complained about the amount of bouncing around and the general chaotic nature of the presentation. What I viewed as a bonus to the audience was actually a distraction: They couldn't really tell what I was doing because I was bouncing around so much. It made me realize that most of the activity within my presentation didn't really make it more effective, but rather stroked my ego: It was a demonstration of how much I could maintain my concentration during a performance, rather than the best way to convey information.
That evaluation form made me reconsider doing primarily live demonstrations; in modern terms, I accidentally implemented the Dead Demo antipattern rather than the Live Demo pattern. My presentations had all the hallmarks of a Dead Demo:
- I wasn't showing something that only made sense within a tool.
- I was spending lots of time getting everything set up at the expense of real content.
- I was mostly showing how effectively I could use tools while an audience watched.
In other words, it was more about me than about the audience.
I had come to this style of presentation honestly, because I had a long experience with technical training classes. In a classroom setting, where I was teaching a group of adults how to use a particular tool, the Live Demo style worked great because the students were required to use the tool for exercises. Standing up front and building bespoke things using a tool was in fact the best way for me to convey that information, and it still lives as one of the positives of the Live Demo pattern. What I hadn't realized was that the context of my talks had changed, from the training room to the conference hall. For conference presentations, the focus is less on repeatability than information density, and my now Dead Demo presentations didn't cut it. I had missed another of our patterns, Know Your Audience.
The No Fluff, Just Stuff evaluation made me realize the error of my ways, and I gradually started building more formal presentations, rather than leaning on live performance to entertain the audience. I found that I could greatly increase the information density of my presentations because I wasn't wasting time typing and using tools in front of the crowd.
'Old-Fashioned'
Presentation Patterns: Techniques for Crafting Better Presentations distinguishes between an Infodeck (slides designed for reading by flipping through them) and a presentation (leverages time via slide animations and transitions). By 2007, I had largely given up doing Dead Demos. However, like many other technical presenters, I made the mistake of presenting Infodecks instead. I hadn't yet caught onto this important distinction. But I had started to think more about the visual content of my slides.
Another epochal event occurred on the No Fluff, Just Stuff tour in 2007. By this time, I had added quite a lot of visual interest to my presentations, but without adding much value. I realized that using the default templates and fonts was a bad idea (now captured as the Defy Defaults pattern), so I had customized my background, inspired by a famous painting by Mark Rothko, an abstract expressionist painter. I had also switched from PowerPoint to Keynote, giving me a broader visual palette. Basically, most of my slides looked like the one in Figure 2.
)
Figure 2 A slide from my "Productive Programmer" talk, circa 2007.
I was proud of the visual density of this presentation, including the little tip box that animated in from the upper-right corner to consolidate the advice on the slide. But, lo and behold, I received an evaluation from a No Fluff, Just Stuff attendee saying, in essence, that the content was good, but the presentation was "old-fashioned." Old-fashioned?! How could he mean that? I was using a custom background and state-of-the-art three-dimensional bullets for my slides!
That evaluation caused me to rethink the visuals for my presentations from the ground up, and I started researching the current state of the art in presentations. This exploration led me to Presentation Zen, Nancy Duarte's slide:ology: The Art and Science of Creating Great Presentations (O'Reilly, 2008), and a fundamental rethinking of how my presentations could look. This single revelation had the most profound effect on how I built slides. It literally allowed me to see this tool I had been using for a decade in an entirely new light.
My 2009 presentations were a combination of highly visual, raw, and clumsy, as I was learning a new presentation style while still presenting at 30 to 40 conferences a year. I'm embarrassed by how long it took me to understand the animation distinction between "after previous slide" and "with previous slide," but I eventually learned all the hidden parts of presentation tools. My presentations gradually got better as I continued to listen to feedback and honed my new visual style. While those presentations look primitive today, I was starting to discover my modern style through those early talks and keynotes. One of the reasons I'm successful today is that I had the opportunity to do it poorly long enough to practice and get better, which is the real key to learning.
Toward Patterns
One of the side effects of speaking at numerous conferences is exposure to lots of other speakers and presentations. In particular, I started noticing presenters who hadn't moved on from the Bullet-Riddled Corpse, Dead Demo style of presentation. During one such voyeuristic attendance to one of my colleagues' presentations, I was struck by how stultifying seeing long lists of bullets were to the audience, and the phrase Bullet-riddled Corpse popped into my head as a way of describing that feeling. What I had done was identify my first antipattern for presentations, which was a collision of worlds for me. In the software world, the concept of design patterns is widely used, stealing the idea of patterns and antipatterns from Christopher Alexander, an architect (the building kind, not the software kind) who wrote the book A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977). Alexander catalogued and categorized recurring architectural patterns he observed that spanned cultures, regions, and time. Other architects viewed Alexander's book as an interesting new way of grouping and thinking about similar elements and styles, but didn't see the book as revolutionary. However, Alexander's book inspired similar efforts in other fields.
The pattern concept was popularized in the software world by the seminal book Design Patterns: Elements of Reusable Object-Oriented Software, affectionately called the "Gang of Four (GoF) book" after the collective nickname of its authors (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides). Software engineers use the pattern concept to describe many common problems. The GoF book defined a format for patterns that became a loose standard throughout the software world. Coming from the software world, I was predisposed to categorize the world into useful and less than useful concepts. Applying this concept to presentations was the memetic leap that led me to write Presentation Patterns: Techniques for Crafting Better Presentations with Matthew McCullough and Nathaniel Schutta.
Why "patterns"? Isn't a pattern the same thing as a recipe? The "pattern" metaphor works better than the more familiar "recipe" for several reasons:
- First, patterns operate at a lower level than recipes. A recipe has steps, which consist of instructions such as sauté or peel. Patterns are like the lower-level steps found inside recipes: They're the techniques you must learn to be considered a master chef or master presenter. You can use the patterns in Presentation Patterns: Techniques for Crafting Better Presentations to construct your own recipes for different contexts, such as business meetings, technical demonstrations, scientific expositions, and keynotes, just to name a few. Abstracting ideas to the level of patterns allows for encompassing all types of presentations.
- The second reason for choosing pattern over recipe is for the sake of the concept of antipatterns: There's no such thing as an "anti-recipe," but the book discusses lots of antipatterns—things you should avoid doing in presentations. Unfortunately, modern tools encourage such ineffective presentation techniques.
- Third, pattern names encapsulate a concrete concept; you can convey a great deal of information with a concise term. Once you learn the patterns, they become shorthand when talking or thinking about presentations. A pattern name like Context Keeper conveys not just the general definition, but all its positive and negative connotations, its applicability, the consequences of using it, and so on. Patterns become a professional vocabulary, allowing you to talk about presentations in a more concise yet precise way.
Applying patterns to presentations was a stretch, another in a long string of potentially specious relationships that pop into my head from time to time. Yet, I couldn't give up this idea. I continued identifying patterns (and antipatterns) in my own talks and others'. I thought about writing down this concept, but at that time the concept of patterns was still restricted to technical presentations; I realized the audience for such a book would be entertaining to my presenter friends, but not many other people.
Having stewed over this concept for a while, I started discussing it with frequent presenter colleagues such as Matthew and Nate. Being software geeks themselves, they picked up on the applicability of this concept right away, and started helping me name new patterns. After many discussions, we realized that a good general-purpose concept lived here, because the lingua franca of corporations is the slide deck (enterprise-speak for presentation), yet no one is given proper instruction on how to use presentation tools effectively. Once we realized that, we knew that we had a revolutionary book idea on our hands.
Since that time, I have continued to try to innovate in my presentation content and style. My modern presentations have a distinctive look and narrative style, but each one has its own "personality." Consider a few slides from my "Emergent Design" talk, shown in Figure 3.
)
Figure 3 Excerpts from my "Emergent Design" presentation.
Contrast this style with the "chalkboard" theme I adopted for my "Functional Thinking" talk (see Figure 4), which introduces a style of programming closely related to mathematics, visually harkening back to math class.
)
Figure 4 Excerpts from my "Functional Thinking" presentation.
Or consider the style I used for a talk entitled "Build Your Own Technology Radar," which uses cleaner fonts and a sparser visual style, as shown in Figure 5.
)
Figure 5 Excerpts from my "Build Your Own Technology Radar" presentation.
Each of these presentations has a unique Unifying Visual Theme, designed to complement and amplify the subject rather than detract from it. Now that we have an effective framework—patterns—that enables more clarity of thought about "how" to deliver ideas effectively, my coauthors' presentations have undergone a beneficial evolution similar to mine.
The Journey
In many ways, Presentation Patterns: Techniques for Crafting Better Presentations represents the journey of discovery that my coauthors and I have experienced in learning how to communicate effectively with tools. Three things made it possible: First, the constant feedback offered by conference evaluations, especially from the No Fluff, Just Stuff tour, allowed me to experiment with different styles and quickly find out what works and what doesn't.
Second, I'm willing to constantly reevaluate the things I create, from source code to writing to presentations. I believe there's always room for improvement, and I continually seek opportunities to make whatever I do better.
Third, I'm willing to follow wacky ideas to their conclusion. When I first had the flash of inspiration to apply patterns to presentations, I initially dismissed it as yet another "crazy idea." But sometimes crazy ideas just won't go away, no matter how much I try to ignore them. Eventually, I realized I needed to write this one down as a form of exorcism, and writing it down finally allowed me to take it out of my head and put it onto paper. Fortunately, I was able to find coauthors who also thought my idea was crazy, but not too crazy to put out into the world.
So we did.