I am working on the Google IO sessions; this includes a large number of rehearsals. One premise of IO is that we put actual engineers, the people who build the good stuff, on stage; they deserve, and receive, support in polishing their material.
I’ve observed that every good early-stage presentation is good in its own way, but that many of those that need work need the same work.
All this has been said before, but it can’t hurt to say it again. Adapted from an internal email.
Death to Bullet Lists · Few things are more boring than an engineer reading words out of lists to a room full of people, all of whom can read.
Your slides are not your content. What you say and the demos you show are your content, the slides are there to support and explain and background. Here’s what happens when you put up a bullet list: The audience reads all the bullets in the first 15 seconds, nods their heads, and decides to check their email while you drone your way through them. One presenter I saw had the genius idea of progressive-revealing the bullets, and that’s even worse; the audience read the first bullet then turned to their email and didn’t even notice when you brought up the subsequent ones.
Bullet points may be appropriate when listing strategic design choices, explaining enum values, and so on. If you really must use them, they should be really short, ideally a word or two, and you use them for a launching pad to take up your subject in depth. Two things that are always better than bullet lists:
screen shots, showing the effect you’re talking about.
[Especially] Code samples. A code sample is almost always a win, and if you stand in one of the session rooms looking at the audience, when there’s code on the screen you see faces looking up at the screen, and at the speaker talking their way through the code.
Agendas · A lot of people start the talk by putting up a bullet list of the things they’re going to talk about, and then reading it to the audience, who are all doing email by the third bullet. You published an abstract. The audience had to choose between like 12 tracks; they know what they came to see.
The first few seconds of your talk are a golden opportunity to grab the audience’s attention and make it memorable. Good things to do include a poll (“How many people here have...”), a story (“I’m blind and I can use an Android device just fine”), or a lurid claim (“This talk will help you avoid being featured in TechCrunch for a major privacy breach”).
If you must MUST tell them what you’re going to tell them, do that while your welcome slide is still up. Want more convincing? Go look at YouTubes of famous/popular/well-known presentations by famous/polished/well-known speakers and count the number that begin with agenda slides.
Comment feed for ongoing:
From: John Cowan (Jun 07 2012, at 22:58)
The problem with screenshots and code samples is that the type is too small to be legible from the back, and sometimes even from the front. (This doesn't apply to screenshots that are primarily graphical.) I use code samples only if they are seven lines or less.
My slides are bullet point headlines; that is to say, they are *sentences* that tell the shortest possible version of the story. (Headlines are not captions.) I then elaborate on those headlines extemporaneously. Even if you don't hear a word I say, you get the complete, if detail-free, story I'm presenting.
[link]
From: Tropical Storm Akoni (Jun 08 2012, at 01:56)
Bullets are only part of the problem. Ever take one of Edward Tufte's classes? He just loves Powerpoint (yeah right).
[link]
From: Hans Petter Eide (Jun 08 2012, at 02:43)
Neal Ford gave a fantastic presentation on this topic at JavaZone last year. It's available on Vimeo: http://vimeo.com/28724526
[link]