Some of my usual tips for students who are designing a technical talk.
A polished talk makes a lasting impression. A weak talk means you just wasted a year doing research that no one will read. Either way, the audience members will draw conclusions about you and your work. The good news is that it's fun to get them excited about your work. The more good talks you design, the easier it becomes, and the more people will come hear you!
It makes me happy and excited to give a talk that is well-crafted and supported by pretty slides. I'm excited not only to share the technical ideas in the talk, but to delight the audience.
Talks and papers are both forms of teaching. Much of the same advice applies. However, a paper must do double duty as reference material that lets anyone verify your work. Your talk's only obligation is to be clear and entertaining:
Clear. Give your audience that "aha!" moment of understanding. They should be able to tell their friends exactly what your key idea was.
Entertaining. Your audience should remember your talk for at least a year, so that they'll read or recommend your paper when it is relevant. To lodge in their mind, you gotta get a gimmick. A conference has so many talks that most are quickly forgotten: but not yours!
In other words, the audience should understand you while you're talking, and your memorable gimmick should help them recover that understanding later.
Rereading your paper is certainly a good start—you worked hard on it and it's a good source of material. You might very well want to organize your talk the same way as your paper. But your talk needn't follow the paper exactly:
Also remember that you'll be talking:
It's a mistake to start making slides right away. First you need to design the flow of the talk. Don't get bogged down in Powerpoint or Keynote hacking before you know what role each slide will play.
Step 0: Getting perspective. Teaching begins with extracting your head from wherever it's stuck. You are an expert, deeply wrapped up in the problem. Your audience may be as smart as you, but they know so much less, and they're so much less invested! Take a deep breath and prepare to see the work through their eyes.
Step 1: Whiteboarding. Explain your work to a colleague, at a whiteboard. You are improvising, so monitor their reactions! You are looking for a magic incantation or drawing that will make the light bulb go on over their head. It may take several tries. When you hit on an approach you like, write it down. You haven't explained quite everything yet, so figure out how to get the next light bulb on ...
Now explain your work to another colleague. It should be easier this time. You're mostly testing your incantations from last time, but you may also try out some new orders and new ideas.
Step 2: Setting goals. Write down 3 technical things that the audience really needs to understand. Also write down 3 messages that you'd like your audience to take away from the talk. In your talk, you will state these messages explicitly, and you'll also convey them by how you choose examples and allocate time.
Step 3: Outlining. Draft an outline. Regardless of the hierarchical structure, each section should flow naturally into the next.
Step 4: Storyboarding. Get a stack of blank printer paper. Yes, physical paper! Sketch out one slide per page, using colored pens. Slides are just visual aids to support you as you talk. So, talk away, and revise the slides as you go! Paper slides are easy to sketch and annotate, and easy to edit, shuffle, and replace when the sequence isn't working for you. You don't have to spend time drawing small details that you can imagine. However, sometimes you'll want to carefully sketch actual layouts for important diagrams, and write out actual text for titles and bullet points.
Step 5: Slidifying. Once your advisor has given constructive feedback and helped you improve your storyboard, make the electronic slides. Your first pass can leave some details to fill in later. Use Keynote, Powerpoint, or perhaps sfig. I recommend against Beamer or SliTeX (see below). Google Slides allows your collaborators to edit or comment, but has fewer features.
Step 6: Rehearsing alone. Practice the talk with a timer. Do not skip this step! You'll need to run through the talk several times. The first time I run through a 20-minute talk, it usually takes me over an hour, because I am experimenting with different phrasings. When I hit on a clear, concise phrasing, I jot it down (perhaps in the notes attached to the slide). If I can't find a good way to talk about a slide, it's a sign that I need to change the slide deck. Often it means I need to back up and fill in some supporting ideas.
Step 7: Practicing with an audience. After you've rehearsed a bit on your own, deliver your talk to a few colleagues—try to include some newcomers who don't know your work. Get feedback. Revise your story and your slides accordingly. If there's time, give a second practice talk to make sure that the new version works.
Step 8: Final timing. Really polish the talk—stand in front of a mirror when practicing. Make sure it's down to 20 minutes (or whatever) and that you feel comfortable giving it.
In all these steps, you are working toward a clear and entertaining presentation ...
Framing your argument. It's not enough to present a list of true assertions. Think about other fields:
The only way an audience can follow a collection of ideas is if those ideas fill the slots in some narrative structure or argumentation structure. Tell a story!
Choosing an order. The basic problem is to linearize a complicated network of ideas. As I explained in an interview about teaching:
[We experts have] all the formalizations, techniques, and examples in our heads at once, and they're bonded to one another in a dense ball in which everything follows from something else. If we pull on any one idea it just snaps back into place.
But to teach, we have to cut some of those bonds and unfold the structure into some linear presentation that will then fold up correctly again—like a protein—in a student's head.
[Protein design is NP-hard, so heuristic techniques are used. The previous section encouraged similar strategies for talk design—coarse-to-fine search, stochastic local search, birectional search, etc.]
"Oh, just one more thing." One handy type of linear structure is to start with easy stuff, and then tweak the audience's understanding bit by bit. Every few minutes, the audience should feel like the talk is essentially complete—but then you confide that there's one more detail you want to share:
This structure keeps the audience appeased. It doesn't let important questions fester till the end of the talk; it promises at every turn that just a few more minutes of attention will be well rewarded; and it yields a good experience even for audience members who lose the thread before the end. (It's like the inverted pyramid of newspaper writing.)
Pictures and diagrams. Most slides should be pictorial. If you have a lot of text on a slide, replace it with a diagram or animation that communicates the same ideas. You need to figure out how to draw the idea. Concrete examples are your friend here.
Finding the right example. A running example helps to tie the talk together, and it reduces the cognitive burden on the audience. Get the audience engaged early with a concrete problem, and show throughout the talk how each idea acts on that problem. As I've written elsewhere:
Running examples greet the reader like old friends. The [audience] will grasp a point more quickly and completely, and remember it better, when it is applied to a familiar example rather than a new one. So if possible, devise one or two especially nice examples that you can keep revisiting to make a series of points.
Consistency. For the same reasons, you should use a consistent visual language. Choose a few colors and fonts. Specific colors and fonts should consistently mean the same thing—plan this out at the storyboarding step. Your terminology and notation should also be simple and consistent. Reuse graphic elements mercilessly across slides.
Knowing what not to explain. You can't teach everything in the allotted time. If you try, you may end up with a cramped section that no one will understand, unless they're already quite familiar with it. Cut this section and replace it with something higher-level.
Opening strong. The beginning of the talk is special. It has to hook the audience. They're all deeply tempted to "glance" at their email. Make them put those phones away! Convince them that this talk will be (a) interesting, (b) important, (c) fun and easy. They'll listen if they think they're in good hands.
As you plan out your talk, you should also find a couple of ways to make it awesome! You're performing up there (and building a fan club for your future talks). There are practically no restrictions on what you're allowed to do for the sake of a good show. Your talk should stand out from all of the other talks in the conference.
Have fun and keep your mind open when you're batting presentation ideas around at the whiteboard. If you make a joke or use a goofy metaphor, consider running with it. If you're waving your hands around, is that because you see animated graphs in your head?
The fun stuff does need to support your technical story, not distract from it. It's what people will remember best, so it should be connected to the meat of your talk. The goal is to convey the technical ideas quickly, clearly, and memorably. Here are some ideas:
Metaphors / analogies. An analogy builds on something your audience already understands. Many good analogies are entertainingly whimsical and can resonate through your talk, guiding your choice of examples and clip art. My talks as a grad student used fruit trees, stacks of hats, Communist revolutionaries, asylums, ... I still love analogies!
Stories. Can you motivate your problem, or describe your solution, by constructing a fable? Everyone loves stories about Alice and Bob (who may be users, computational processes, bemused students, competing terms of an objective function, Lewis Carroll characters ...). True stories can also be compelling.
Aphorisms. Can you boil an important idea down to a pithy catchphrase? Put it in big type on its own slide, and keep coming back to it!
Algorithm animations. You may be able to programmatically generate an animation of your algorithm. If that's too hard, you can do a mockup using your presentation software's animation features.
Physical props. When did our community agree to stare at a projection screen all afternoon? If you have a physical analogy or a story, bring objects and manipulate them in front of the audience!
Confederates. No one said that a talk has to be a solo affair. Two speakers can give a talk jointly, perhaps even staging a skit where one is questioning or challenging the other. You can also plant someone in the audience.
Photos, videos, clip art. Some talks stand out as strongly visual. The web is full of images. It's also easy these days to take your own photos or videos, or perhaps you can draw or commission cartoons.
Audience participation. If you ask the audience to guess something, it's instant engagement. Your question should be neither intimidating nor obvious, so that people want to answer. You can call on a couple of people or do a show of hands. Then reveal the actual answer.
Wit. Throwing in some little jokes along the way keeps the audience's attention and energy up.
An admission: This webpage is pretty clear, but I forgot to plan any awesomeness and now it's too late. (It's also all texty bullet points—good thing it's not a talk!)
There's lots of advice on the web about slide design. Search it, but here are a few basic rules of thumb.
Timing. Standard advice is 20 slides for a 20-minute talk.
Layout. Don't be cramped, cluttered, or wordy.
Accessibility. Be considerate of your audience.
Emphasize the organization and the main message.
Arrive early. Tell the session chair how to pronounce your name, confirm how you'll be timed, and check the A/V equipment.
Memorize your first few sentences so that you'll be able to ease into the flow even if you're nervous or distracted. Keep a good pace, but stay relaxed and positive.
Listen to yourself talk, and pay attention to audience reaction, which will alert you if you misspoke. If you get a clarification question, don't automatically answer what they asked: figure out where they're confused and answer that.
Questions at the end give valuable feedback. They keep the event interesting and show that the audience is engaged. Again, listen to the question, think before answering, and stay positive. In a longer talk, it's nice if you can pause periodically for questions, or let the audience know that you don't mind being interrupted.
Hopefully it won't go as envisioned in PhD
Everything gets better with practice. Over time, you'll learn to spot problems with a talk design, and you'll accumulate a bag of tricks for solving these problems.
A cheap way to practice: Pay attention to the design and presentation of other people's talks. Some speakers are great at laying out a complex idea and engaging you along the way. Try to figure out how they did it. Conversely, if you're in a talk that is boring or hard to understand, you can still get something out of it— shift your attention to diagnosing the problem. That's actually how I learned how to teach: I had some bad teachers, and came away with a list of things to do differently.
|Jason Eisner - firstname.lastname@example.org (suggestions welcome)||Last Mod $Date: 2020/06/04 02:54:31 $|