Preface

In grad school, I've sat through hundreds of presentations at conferences, seminars, and graduate classes. I've also had quite a few of my own presentations critiqued by other students and professors. Here are some tips and observations based on my experiences. Hopefully these are beneficial to CS grad students looking to improve presentations about their technical papers (both in style and content). Given my background, the specific focus of these tips is more on systems and networking research.

You can go to my publications page to see examples of my presentations (note that I've learned these tips progressively, so all of my presentations may not necessarily adhere to these tips). Also, my adviser's slides are available on his research group's site.

If you have any other tips for this list, email me and I may add them.

Tips

• Supplement, Don't Summarize: Some of the most uninspired talks I've seen are ones where the author basically just presents the exact same content from the paper in the exact same order as the paper. The audience could have gotten the same information by just reading the abstract and glancing at the figures in the paper. Most of the better talks I've seen take the approach that the presentation supplements the paper to help the audience better understand the work.

  The presentation doesn't have to be strictly encapsulated by the material in the paper. Provide interesting and/or humorous analogies. Use animations to describe protocols and algorithms. Include subsequent results since the paper was published (there's usually a several month lag in when the paper is accepted and when the presentation is done). Ideally, even someone who has already read your paper can still benefit from attending the presentation by more clearly understanding the contributions, design, and results of your work.

• Win the Competition for Attention: In these days of wireless Internet and cell phones, there is lots of competition for the audience's attention. You probably have at most a couple of minutes and/or slides to convince them that what you have to say is worth listening to. People form impressions quickly (read Malcolm Gladwell's Blink). If you can't capture their interest relatively quickly, then they'll bust out their laptops and start checking email.

  This means that your first 2-3 slides should be designed to get the audience's attention. Use pictures. Give a brain teaser related to your algorithm. Include a relevant reference to something outside of CS. Technical presentations don't have to be necessarily boring. I've seen some amazingly entertaining seminar talks given by professors talking about their research. Give them a high level overview of the significance of the problem being addressed and how your solution fills the existing gaps.

• Concentrate on Math at a High Level: Here's a great way to lose your audience: put up slides covered from top to bottom with mathematical equations that were cut and pasted from the paper. You'll immediately lose everyone in the room save for the handful of people that are currently working with the exact same math. The paper is a good format to describe the inner workings of your math...the presentation is generally not. A better way to handle math is to selectively choose the best equations to get your point across and concentrate on explaining intuitively what the equation means rather than the details.

  Also, make sure that the notation being used is clear. Putting up some equation with twenty variables and telling the audience that the descriptions are in the paper probably isn't going to benefit anyone. In the presentation, you can abstract away insignificant and minor variables since the details are in the paper.

• Get Animated: Make full use of your medium by adding animations to describe your protocols, concepts, and algorithms. This is an area where slides are superior to papers since you're no longer restricted to static figures. Of course, there is a danger that you can overdo it with animations, but I've seen far more presentations that don't use animations enough compared to those that use it too much. Make sure the lines, text, and objects in the animations are big enough to be seen by the entire audience.

• Make Figures Presentable: First, if you're going to cut and paste a figure from your paper, make sure that the resolution is sufficient for the slides. The way I do this is by using the native document reader for zooming before doing a screen capture. For example, if you have a PDF document for your paper: (1) open it in Adobe Reader, (2) maximize Adobe Reader, (3) zoom in until the figure fills your entire screen, and (4) do a screen capture (e.g., by pressing Print Screen in Windows or with GIMP in Linux). I then usually open the resulting image in MS Paint and crop it before pasting it into PowerPoint.

  Many times just cutting and pasting the figure from your paper isn't enough. You probably need to modify figures for your slides. For example, a graph may have five curves in your paper for completeness, but for the purposes of clarity, you only want three curves in the presentation graph (this can be done with the erase function in MS Paint). When a graph is placed on a slide, it may be beneficial to remove the original key and use arrows and text from PowerPoint to identify the curves. Also, the axis titles and values may be easier to read if you insert the text via PowerPoint instead of using the fonts from the paper.

• Minimize the Amount of Text on Slides: Slides typically use bullet points to make 2-3 main points per slide. A poor presentation technique is to put paragraphs for each bullet point. The audience just doesn't have the time or desire to sit there and read sentences of text during the presentation. That's what the paper is for. Remember when you're making the slides that the audience wants to read them as little as possible to understand. If you do have to use several lines of text (e.g., when using a quote to make a point), then highlight several words that convey the main point (e.g., using bold face or a different color).

• Anticipate Audience Questions: It usually helps to include some extra slides at the end of your file that aren't part of your presentation, but can be brought up in response to audience questions. These slides may justify some of the assumptions from your work or include additional figures from your paper. You don't need to break the flow of your presentation my including these slides, but just have them available in case someone asks.

• Use Colors the Audience Can See: Never use yellow or lime green text on a white background. This color scheme usually looks all right on your computer, but fails miserably with a LCD projector. The audience can't see it. Plus, it indicates that you probably haven't practiced in front of an audience.

• Adhere Strictly to a Minimum Font Size: Never use a font smaller than 20 point on your slides. You audience won't be able to read it. If you need something this small, you're probably trying to cram too much on one slide anyway.

• Exceptions to the Font Size and Color Tips: Of course, every rule is made to be broken and there are a few times when you want text on your slide that the audience can't read. One example is if you're citing another work. In this case, I use a light blue or gray font so the information is there, but it doesn't distract your viewers during the course of the presentation. Another use is if you need to place a copyright notice next to an image, for instance. Here, I'll usually use a small (e.g., 8 point) font close to the image. Again, the information is there, but you don't want to waste much space with a copyright notice that distracts viewers.

• Use a Sans Serif Font: While serif fonts are better for reading papers, sans serif fonts are easier to read in the slide format. In PowerPoint, Arial and Comic Sans MS are popular choices.

• Make it Easy for Viewers to Reference the Slides: Number your slides. This makes it easier for the audience to refer to a specific slide when they have a question (or, in a practice presentation, when someone is helping you debug your talk). And, label the objects in your illustrations. For example, in networks, presenters usually use circles to represent nodes. With labels, the audience can ask a specific question like, "What happens if node A transmits to node B while C is transmitting to D?". Such questions are much more difficult to communicate if you're not using the appropriate labels.

• Use a White Background: This is more a matter of personal preference, but I can honestly say that I've never seen a technical presentation enhanced by using some other background color.

• Practice and Get Feedback: Volunteer to speak at a group meeting or department seminar. Bribe people with free cookies. Get feedback from a practice run before the real thing. Most likely, there will be some implicit assumptions that you didn't think twice about that totally confuse someone not as familiar with the work. Or, you'll start trying to talk about a slide and realize it's much more complicated than you thought when going over it in your head. And, of course, there's probably a few errors on the slides. Practicing will help you catch these things. Also, you'll get a feel for the questions that people have so you can include appropriate figures and extra slides.

  Don't get discouraged if people have lots of criticism for your work. In academia, one's lifeblood is being able to come up with ways that things can be improved. In my experience, no matter how many iterations of revisions you do with a professor, they will always be able to come up with some way to improve the slides. It's about iteratively getting better, not achieving perfection.