Recall that in Part 1 of this series, we laid out a collection of different types of talks and then identified what has to appear in each of those talks. We've been working our way through these and today's topic is the laid out in the third column as the "Work in Progress" (WIP) talk. It may also be a talk that goes along with a poster.
The parts that need to appear in a WIP are: The fairy tale (of course), motivation, your work, evaluation, conclusion. Mostly, I like to think of this as a simple expansion of the fairy tale: to a first approximation you are basically going to have approximately one slide for each part of the fairy tale. In all likelihood, you'll have more than four slides, but you probably won't have 10. So think about it as: 1 "once upon a time", 1-2 introduction of the villain, 1-3 introduction of the hero, and 1-2 for the happily ever after which might include results and/or next steps and will certainly include a reminder of why this work is important.
Lest you think that these talks are simple, throw-away talks that don't really require a lot of effort, I want to highlight two instances of such a short talk with enormous consequences: 1) pre-COVID, the papers that were not quite good enough for Oral Presentations (of which there were maybe 15) were selected as Spotlights (around 50 of these, out of the approximately1500 papers accepted) and were given a 5-minute talk slot. 2) The Bell Labs Prize Phase 2 competition requires that teams summarize their work in a slide deck not to exceed 10 slides. Needless to say, a lot of time/effort goes into these short talks.
The Cover Slide
I can see and hear you now: You are rolling your eyes and thinking (or even saying out loud), "You have got to be kidding me -- she wants to tell us what to put on our cover slide? And the answer is, "No." I believe that you know what to put on your cover slide (the project Title, your and your collaborators' names) and ideally some logo or graphic or picture. However, I am going to talk about what to say when you begin your talk.
What not to say: Please, please, please, do not simply read your slide to the audience. I have sat through so many talks where the session chair says, "Next we'll hear from person, who is going to talk about title." And then person gets up and says, "I'm person and I'm going to talk about title." And, of course, the entire time, I've been staring at a slide that says, "Title" and has an author list with person's name in bold.
I hope by now you realize that if all you do is read your title and name, you are duplicating information and missing a huge chance to get the audience interested in your work.
If, and only if, A) you have not been introduced, B) the audience does not know who you are, and C) you have co-authors, may you introduce yourself.
Then, rather than read the title to the audience, explain why they should care what you are about to tell them for the next five minutes. This might be the 'once upon a time' of your fairy tale; this might be an explanation of your work that avoids buzz words that might appear in your title; this might be a question, i.e., "Have you ever wondered ..." Whatever it is, give the audience something that they will not get from simply reading your slide.
I'm going to pick four random titles from HotOS (the last event I attended) and offer some cover slide material.
Putting out the hardware dumpster fire -- Some of you probably already heard this, but I'd say something like, "Today's hardware is really complex, and for the most part, when we talk about operating system security, we completely ignore this complexity. As a result, I'm going to claim that we aren't really solving the problem that we think we're solving, and I'm going to offer some suggestions for actually solving the hard problem!"
First, Mothy needs to introduction in our field and second, these few sentences are much more descriptive than the title, which I still believe is entirely wonderful.
Degrading Data to Save the Planet -- We will never have less data than we do today! Every day, we produce far more data than we destroy. More importantly, producing the devices on which we store this data (i.e., flash) produces significant carbon emissions. Let me tell you about our new sustainable storage design.
Doesn't that tell you a bit more about what's to come than the (also great) title did?
Towards (Really) Safe and Fast Confidential IO -- Customers do not trust their cloud providers! Confidential computing is an approach to using cloud resources in a way that does not reveal confidential data to the cloud provider. Unfortunately, today's work in confidential computing mostly ignores information that is revealed through IO APIs. Let's talk about how we can improve on this situation.
Once again, I think this tells you more about what's coming than the (perfectly fine and accurate) title.
Automatic kernel offload using BPF -- I explicitly picked this one, because the title tells you exactly what this paper is about. Even so, I think you can say something here that tells your audience more.
The extended Berkeley packet filter (eBPF) has become the de facto approach for running kernel extensions. But how do you decide what should be offloaded? Offloading the wrong thing can produce terrible performance. Let me tell you about a tool we developed to automatically figure out what you should offload to eBPF.
See -- I bet you did not realize that that's what this paper was about.
So, having now written an almost entire blog post on your cover slide, let's move on.
The Once Upon a Time
Others, less well-versed in fairy-tales, will tell you that this is the motivation. They are partially correct -- the motivation is actually the combinination of the once upon a time and the villain. In a short presentation, the once upon a time may also be short -- you just to have place the work you're going to talk about in the right setting. Is this a paper about data centers? containers? isolation? performance? security? privacy? formal verification?
If you are presenting a short talk, chances are that you are one of many talks in a session and there might be little or no relation between the talk before you and yours. That makes it all the more important to help your audience get in the right mind set for your paper.
Consider the Degrading Data paper above. If the paper before you was on disaggregated memory, the audience is primed for talking about in-memory data; if they paper before you was a storage system paper, they are primed for a storage system talk. You want them primed for your talk.
The Villain
Now that you have your audience primed, you really need to motivate them that your work is important. What is the problem you're solving? Do not assume they agree that the problem you are solving is A) important, B) interesting, C) feasible. You need to convince them that they actually care about your problem.
Sometimes the villain takes the form of a story (i.e., "Imagine that you are ..."). Sometimes it could be a performance problem, "Have you ever done X and then had to sit there and wait until Y?" It could be something the user has never wanted to do, "If you are a networking researcher, packet traces are worth their size in gold!" (So, even if the listener is not a networking researcher, they ought to be able to appreciate that someone who is would find packet traces valuable.)
The more concrete you can make the problem the better. Compare, "Keeping data safe is important," to "Customers lost twelve trillion dollars when this very specific bad thing happened." That ought to make people sit up and take notice. Even if they are not data geeks or security/privacy experts, the thought of losing twelve trillion dollars is likely to seem important.
The Hero
This is where things get hard. I think that with focus and a bit of thinking, you can really nail the context and the problem, but how do you summarize everything you've done in only 2-3 slides? You don't! Focus on the big picture and maybe (just maybe) one technical detail.
What do we mean by the big picture? This is not necessarily a detailed block diagram of the 100,000 linse of code that you've written to build some system. Instead, what are the three key ideas that you've had to solve this problem? How do they fit together?
I've spent a fair bit of time developing short 'research vignettes' that let me describe research in myriad different areas to a general audience. Each of these is really just a short talk. Here are some examples:
For part of a PLDI keynote, I summarized a student's MSc work (tens of thousands of line of code) in four slides: context, picture that shows what the student produced while my voice over explained why we were trying to do it, picture showing the key decomposition approach that let him solve it, and a slide with one key technical approach used to in solving the problem.
At a recent talk at Duke, I summarized another student's MSc work in 6 slides that used the same primary picture on each slide and then added different pictures on the side to illustrate how he solved the key parts of the problem.
It takes awhile to get good at capturing the essence of the work and explaining things at just the right level of detail. I find it helpful to have a specific audience member in mind. This person is most definitely not someone on your project. They are likely not even working in exactly the same area you are. But they are a computer scientist and they are smart. Think about how you might convince them that they should care about what you're doing and then once you've made them care, figure out how to present your work in a way that helps them "get it" even if they cannot appreciate all the nuance and subtlety.
The Happily Ever After
As mentioned above, the happily ever after must include a reason why it was worthwhile to conduct the work. How have you made the world a better place, even if only a tiny bit? In addition, it can also include, next steps, things you learned, suggestions for future projects, etc. If you can leave the audience wanting to work on your problem, they you have succeeded!
No comments:
Post a Comment