UNIVERSITY OF WISCONSIN-MADISON
Computer Sciences Department
|CS 739: Presentation Guidelines|
Below are some notes to guide you in preparing your presentations.
"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.
"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.
"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."
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:
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
I'd like to underscore a couple of points from Bart's guidelines.
Note that these guidelines are equally valid for oral exams.
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
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
Mark Hill also has a
that are worth reviewing, as you prepare your talk.
Return to CS739 home page.