Below are some notes to guide you in preparing your presentations.

1. Read the paper 3 or 4 times. Or more, until you understand all of the details -- even the un-fun parts. Someone may ask you a question about these, and you need to be able to answer.
2. If there are references in the paper with which you are not familiar, you should check these out.
3. Decide what's important. A paper will have many details, but only a few important ideas. The talk should be organized around the important ideas.
4. Outline your talk. Do this as a top-down design. As a result of this, you fill up the time with first, the important ideas and second, fill in the details to explain these ideas. If you don't outline your talk, it will ramble.
5. Punctuate your talk. An hour talk should have several major sections. These sections should be introduced at the start of the talk.
6. It should be clear when you start a section and when you finish a section. An audience cannot concentrate for an entire hour. Sections give mental resting places. There should be a clear break AND a sensible transition between sections. E.g.:

   "OK, so that's how writing to the log works. (long pause) Now let's talk about recovery after a crash happens."

   Each section should be structured like a mini-talk.

7. There is the old rule:

   "Tell them what you are going to tell them. Tell it. Tell them what you told them."

   This isn't quite right. And it's boring to hear the same thing 3 times. Here's a better way:

   "Lay the ground work. Tell it. Summarize the important ideas."

   Your talks should have a summary slide of the main ideas at the end. You should also list a one or two open questions from the paper, and the class will be expected to suggest more. Everyone please note this! This is your responsibility for each paper.

8. By now, you have all read many papers. Relate what you are talking about to these other works. E.g.:

   "Links in DEMOS/MP are capability-like structures much like ports in Mach or file descriptors in UNIX."

   Use references to both support and contrast. E.g.:

   "The DEMOS/MP paper was able to modify the kernel to implement migration, while Condor had to do it all in user space."

9. Talk with me as you plan your talk. See me two weeks before your talk to present the main ideas and an outline for the talk. Next, meet with me to show a sketch of your talk with an outline for each slide. Last, meet with me to show your slides. This is a requirement, not a suggestion.

Speaking in front of a group can be difficult at first. Most of the time, you are nervous when you start and then relax as the talk progresses. Some points on the presentations:

1. Use color on your slides. Make sure that the color has a purpose: for example, to highlight a part of a figure or to group like things.
2. Use fonts large enough for people to read from the back of the room.
3. Don't cram your slides full of information. Put enough text to present the main points and guide your talk. Don't be too sparse, either.
4. Use pictures. A good picture can explain an idea more quickly than spoken or written words.
5. Humor (jokes) in a talk is a good idea, if you are comfortable doing this. And if they don't distract from the talk.
6. Look at the audience most of the time -- not at the screen or projector.
7. Practice the talk until you are comfortable. Also time yourself. Allow time for questions at the end. Talks can be no more than 50 minutes.
8. Assume 1-2 minutes per slide, on the average (so, about 30-40 slides for a 50 minute talk). If you have many fewer than this, you will be boring people with the slide. If you have many more, people will not have time to read and think about the slides.
9. Keep the slides and the talk in synch. As you present new ideas, you should be putting up a new slide.
10. If you are worried that you will forget what you will say with each slide, write notes on the paper that goes with the slide (write in big letters so it's easy to read).

The talks are your contribution to the class. The important thing is to make a good effort. This is a skill that you'll always appreciate having.

Addition Comments from Marv Solomon

On slides: Never use a lot of text. If you put a paragraph of words on a slide you will have to choose among 3 unsatisfactory choices: Read the slide to the audience; stand there like a dummy while the audience reads it; or talk about the slide while the audience is wishing you'd shut up so they could read. (By the way, the last alternative is the most common, and also the worst.) Use pictures, tables, charts, or outlines with a few keywords. The slide is something to point at, not to read.

On pacing: It's important to make sure the audience knows where you're going. ("First I will outline the nature of the problem. Then I will show that there are seven possible solutions. The fifth one turns out to be the best. I will go into the fifth solution in depth. Finally, I will summarize and mention some remaining open problems.") Remind them periodically how you're progressing. ("We just saw that there are seven possible solutions. I'll only have time to look at the fifth in detail.") There are many good reasons for this approach. One that you might not think of is to keep from getting bogged down in nit-picking questions. Suppose you want to list some definitions and then prove a theorem. The definitions are probably boring. In searching for some interest in the definitions, somebody may ask questions about the details. ("Why is that a set rather than a bit-vector?"). If you get involved in a long discussion with the asker, everyone else will get even more bored and join in the debate. In the worst case, you will spend the whole hour talking about the definitions and never get to the theorem. Remember that you are in charge of pacing. You should know what you want to cover and how long it will take. There are lots of ways of shutting up a heckler ("The details don't really matter; the important point is ...". "I think you'll find the answer to that on the next slide". "We can discuss this after the talk".)

On questions: Listen to the question carefully and do your best to figure out what the asker really wants to know. Beware of reading too much or too little into the question. If someone says, "Could you repeat that last definition?", don't jump to the conclusion that they sees some subtle flaw in your argument and launch into a detailed defense of your thesis. It might just mean that you were mumbling, or they were daydreaming. Simply repeat the definition. If they wants more, he will ask. On the other hand, questioners are not always very careful about the phrasing of their questions. They may use the wrong technical term in a question. Try to figure out what they really want to know and answer the question they really meant to ask. Some questions may reveal a fundamental misunderstanding. If one person is completely lost, it's a safe bet there are many more in the audience. Take a few seconds to try to get them back on track.

Other Presentation Suggestions

Return to CS739 home page.

Last modified: Wed Feb 13 08:55:31 CST 2002 by bart