Assignment #3: Project Presentation

Due Date: Friday, 12/14 by 6am (send slides to me by SIX in the morning, or tell me if you will bring your own laptop)

Location: 4310 CS

IMPORTANT: Bring a PRINTOUT of slides for me!

IMPORTANT: Both you and your partner must present, in roughly equal proportion.

IMPORTANT: Do not thank me in your slides. It is OK -- I know how much you care already. :)


In this assignment, both you and your partner need to make a presentation of your work. The target length is 25 minutes plus five minutes for questions (I will cut you off after 25). A good talk will include a clear statement of the problem you are studying, a discussion of how you went about investigating the problem or solving it or both, results (graphs), and conclusions. Hopefully, a good chunk of the work is finished by this time, but it is definitely OK if it is not all complete, since the paper is due the following week.

There is one other part to this assignment: you must attend at least two other talks. The best way to do this may be to go to the talks in your "session" (talks will be grouped in threes or fours). Of course, you may go to as many talks as you like - they will be open to the public.

When and Where

Friday, 12/14, all throughout the day, in a room 4310 CS.

A presentation schedule will be available shortly, for you to sign up with.

How To Hand It In

Prepare your talk in PowerPoint and send me a URL link to it by 6am Friday morning. This way, I can make sure everything is ready to go when people get to the presentation room.

A Sample Outline

Introduction and Problem Statement. What problem are you are trying to solve or look into, and why is it important? How did you solve it? What were your major conclusions? (state these all up front, then repeat them).
Approach. How did you approach the problem? What is your methodology? Why is this a good way to approach the problem? More details here than in the first few slides.
Results. What have you found out? Present experimental results here. Make sure to both describe what you are measuring, and draw appropriate conclusions. ("Here is a graph showing the performance of our file system under a write-intensive workload. The x-axis varies the file size, and the y-axis shows the time to create a file of the particular size. Each data point is the average of 30 runs. As you can see from the graph, our fancy file system is pretty darn fast.")
Conclusions. What did you learn from the process? What should others take away from what you did? Both specific ("Under our six benchmarks, MyLogFS performed 10-50% worse than Ext2FS") and general ("Perhaps log-structured file systems, while excellent under micro-benchmarks, do not measure up under real workloads") conclusions. Note that conclusions are different than a summary -- a summary is what you did, whereas conclusions are what you learned.

General Advice

Repeat the important stuff. When hearing a talk, it is easy for the listener to miss small parts of what you are saying. Thus, try to pick out the most important results and highlight them, perhaps once at the beginning of the talk, once when you actually present the result, and then once again at the conclusion.
Focus on the first few slides. One of the few places where you have most people's attention is in the first few slides. Spend a lot of time getting these right! I often use the first few slides as a "talk within a talk" -- one slide to present the problem, another to describe how I approached the problem, and a third describing my solutions and results. Then, the rest of the talk just presents more details, and if someone stops paying attention, at least they probably know what I did (if not exactly how I did it).
Use outlines to form structure. Sometimes it is hard for the audience to follow a talk without help. One useful thing to do is to use an "outline" slide to describe the structure of the talk. After presenting the "talk within the talk", I usually put up an outline slide to show the structure of the rest of the talk. Then, as I go through each section, I might put up the outline of the talk again, to show the audience where we are, and how much further we have to go.
Present graphs and experiments clearly. One of the most frustrating aspects of presentations occurs when the presenter does not take the time to explain the results that they are presenting. If you show a graph, explain the experiment, and make sure to explain the graph (what each axis plots, what different lines on the same graph refer to, etc.).
Get the timing right. This is a 25 minute talk. Do not have 30 or 50 slides of real content! You are on a tight budget here, so make sure that you do not go over the allotted time. The key thing to do: practice beforehand, so that you get the timing down. You will be cut off if you run long.
Realize it's all new to the listener. Remember that although you have been thinking about your work for many months, it is completely new to the average listener. Thus, keep it simple! Make sure NOT to assume much knowledge beyond that of the intelligent, 736-educated person.
Above all else, practice, practice, practice! The best way to give a good talk is to give it more than once (in other words, give a bad talk to yourself, improve it, and give a better one to others). Practice aloud and preferably in front of other people. Practicing is certainly the best way to get the timing down. Practicing in front of people not familiar with your work is the best way to make sure your presentation is clear. It's often surprised me how much a talk improves simply by going through it aloud even just once before presenting the real thing.

Advice From Others

Mark Hill's advice on oral presentations

Dave Patterson's "How to give a bad talk" talk