One Motto, Three Rules of Thumb

SSSG[1], the ISR SE program’s weekly research symposium, typically features the SE PhD students (and, less commonly, faculty) presenting either their work, or surveys of the work of others.  From time to time, though, we go a bit meta. This week, I gave a talk on talks, specifically on how I approach the task of structuring a research presentation [2].  I was asked, and am happy, to send out/link to/otherwise circulate the slides. The tricky bit is that they’re heavy on illustrative/goofy pictures and light on, you know, content.  I therefore added a bit of blog-based commentary to go with them (not the full talk, but enough to hopefully render the slides a bit more sensible). The notes roughly follow the slides.

(The irony of course is that an overall theme of my talk is/was that effective written communication is very different from effective oral communication and the strategies required for each are very different.  Whoops.)

Slide 2:  Take everything I say with a bucket of salt.

Slides 3-4: Although many of the principles apply broadly, the context for my comments is a conference presentation.  But even in introducing this context, I committed a (verbal) conceptual error, saying “I will be presenting this paper at ASE…”

Slides 5-9: Motto: I will not be presenting the paper.  I will be presenting the work.  Many presentation antipatterns arise from trying to translate a paper directly into a verbal presentation.  This distinction is subtle but important, because the strategies that inform effective written communication are  very different from those that guide effective oral communication.

Slide 11: I have three rules of thumb:

(1) Your audience will only remember three things.  Fortunately, you get to decide which three things you want them to remember.   One general set of goals for me in a conference presentation is to get my average audience member to remember the first three things on Slide 14 [3].  I illustrate a potential mapping from those high-level goals to the aforementioned ASE paper on Slides 15-19.

(2) Tell a story.[4]  We can assume your work is interesting, since it’s being published.  But even interesting stories are boring if overly detailed.  This is another of the important differences between a talk and a paper:  Papers should support reproducibility.  Talks should not.  Drop all the detail.  Focus on the narrative arc.

My point on slides 22-26 are that a story should have a discrete beginning, middle, and end, and a guiding conflict.  Don’t introduce three conflicts and only resolve one of them.  A single narrative thread should run through the whole thing. Slides 27-36 are then mostly self-explanatory.

(3) Never confuse your listeners.  This one’s kind of subtle. You might think “Of course I don’t want to confuse my listeners! I don’t want to confuse my readers, either!”  But really, we don’t write papers with a primary goal of avoiding reader confusion.  I’m not saying that it’s OK to confuse your readers, just that you don’t subordinate all other things in a paper to the goal of avoiding confusion.  That’s what I’m telling you to do in a talk. This again comes down to the differences between reading and listening (Slide 39).

I discuss two implications of this rule.

First, your listener should always know where you are, and why.  I learned post-talk that my remarks on Slide 41 are related to the psychological concept of ”chunking” as related to memory.  And a note on Slide 42: unlike some, I’m not opposed to outline slides.  I am, however, opposed to the practice of introducing an outline on Slide 3, and then never revisiting it.  This serves no purpose verbally. It can, however, be very effective to revisit an outline to signpost.

Second, never visually overwhelm your listeners.  This problem shows up most commonly in presentation of results.  It’s better to gradually introduce viewers to the results such that they can understand them as quickly as possible [5]; start by explaining what axes mean and how to interpret graphs/tables/etc.   The instant you blast them with a giant table/complicated chart, they stop listening to you and start trying to understand it.

For example, I had a big table in my job talk that I introduced in pieces (selected slides included). I think (hope?) it worked better than just throwing the whole thing up on screen would have.  There was narrative to accompany it, of course.

Speaking of tables, one of the Firm Rules in my research group is as follows: “No talk shall include screen-captured tables, even those presenting someone else’s work; if you must present tabular data, you shall make it readable and pretty. “ Screen-capping graphs can be OK if they’re from someone else’s work because it’s hard to make new one without the data, and I’m not a complete tyrant [5].  Same rules about explaining how to read them apply, though.

Listen: graphs are awesome.  They provide a great way to illustrate complex data and relationships and trends and so on.  But in a paper, we’re trying both to use them effectively and squeeze everything into the page limit.  This is OK, because readers can take time to scrutinize them in a paper without losing the narrative thread.  Not so in a talk.  Avoid translating a paper directly to the screen.

(I warned you it was a theme!)

Then I concluded.  Pithily, one hopes.

There’s way more to be said on this topic, and many different opinions; this is just what I said in one SSSG presentation. For example, halfway through preparing these slides I was directed to some good commentary from Dave Evans on this subject.  Turns out we agree on a lot.  Maybe that’s why I like it?  Anyway, he links to the wise words of others, as well, if you’re on a tear on this subject.

Happy talking!

[1] One (and not the only one!) of those SCS CMU abbreviations whose original expansion has evidently been lost to the sands of time.^

[2] With much less of an emphasis on slide design; I’m kind of bad at it, and Christian totally nailed it with his earlier metatalk.  Also, his recommendation of The Non-Designer’s Design Book is spot-on.^

[3] The fourth thing flows naturally from the first three, so I get it for free.  Whee!^

[4]I guarantee you’ve heard this before.^

[5] Credit where it’s due: Slide 49, which should be animated, is from a presentation my student Mauricio Soto gave about code repetitiveness, which included some of this work from Gabel and Su in 2008.  Slide 49 walked viewers through how to read graphs that he grabbed from the Gabel/Su paper.^