Advice for technical speaking

Shamelessly pilfered from Geoff Gordon's advice page

Don't use too many slides. If you have more than one slide per minute, you are definitely using too many. One slide per two minutes is a much more reasonable pace.

Don't read your slides. You do not need to put everything you are going to say up on a slide; that's what speaker notes are for. Save your slides for things that don't work as well with just speech: figures, diagrams, movies, animations, extra emphasis on important concepts. If your slides are just lists of bullets, they should probably be speaker notes and not slides.

Don't put too many pixels on your slides. Use big fonts and contrasting colors. Projectors are notoriously bad at making ochre and mauve actually look different on the screen. If you copy a figure from a paper, ask yourself whether the text labels are big enough to read from the back of the room, and redo them if not.

Don't try and say too much. You can't explain everything you've been going in a semester project in 30 minutes - part of communicating is deciding what to leave out. If you feel like you have to rush to say what you need to say, you're going too fast: the presentation should be relaxed enough that people have a chance to reflect on what you say, and ask questions if they need to.

Talk concretely about your work. People are great at abstracting from examples, but it's hard work for them to think through high-level abstractions. (This is the opposite case from when you're programming a computer - then you always program the most general case possible, and let the computer instantiate it as needed.) When you're talking to a person, start with a concrete problem you want to solve, and then help the person understand how to generalize that concrete problem to the general case.

View your talk as an advertisement for your paper(s). Your goal is to convince your audience to use your ideas for their own work, so that they cite you and make you famous. Your goal is not to make them understand Equation 43 on page 17 (unless that convinces them to cite you and make you famous). Instead, say what your techniques are good for, why they're important, what the alternatives are, and how to choose when your techniques are appropriate instead of the alternatives. Then and only then, use the rest of the time on technical stuff, with the goal of giving listeners the tools to read your paper. (If you're talking about someone else's work, imagine instead that you're trying to get the audience to trust your evaluation of that work.)

Be honest and diligent. Don't try to cover up flaws or overstate the applicability of your techniques; instead, try to discover flaws and limitations and expose them. Think concretely about your audience. Will they be able to understand each slide as it comes up? Will they understand why each slide is important? As a heuristic, I often find it best to prepare the first version of a talk with one specific person I know well in mind - and think about what I would say to engage and inform him or her specifically.

Talk at the right level for your audience. Remember that, almost by definition, you understand the material and they don't, and fight the inclination to go too fast. Be aware of people's cognitive limitations. Don't make your audience figure something out if you don't have to; that will save more processing power for what you want them to focus on. In particular:

• Don't ask people to listen to one thing and read another at the same time.
• Don't ask people to remember an equation or definition 5 slides later: just put up a copy when you refer to it.
• Use direct, simple language. For example, if there are three ways to refer to something, pick one and use it consistently throughout your talk: don't call something a “model&rdquo on one slide and a “parameter vector” on another.
• Label every graph clearly and in large fonts: both axes, every line, and even the sign of any comparison you want to make (“higher is better”).
• If a fact is important, emphasize it.  The audience doesn't necessarily manage to process every word you say.  Help them process your talk by telling them what is important, and by repeating things they might have forgotten.

Synthesize. The audience should get something out of your talk that they can't get as quickly or easily out of the paper(s). This means: pull together concepts from multiple papers if necessary; compare to related work; communicate your judgement about benefits and limitations of each technique.

Be careful with equations.  You can use a limited number of equations if you want to, but make sure that you spend enough time explaining them that the audience truly understands them.

• Often, it's a good idea to leave the slide blank and hand-write the equations on it during the actual talk; this trick will keep you from going too fast. Of course, this trick only works if you have a tablet or (gasp) an analog device like a whiteboard or overhead transparencies.
• If you use this trick, make sure you practice writing out the equations ahead of time at the same level of detail that you plan to use during the talk.; Don't just assume they're simple enough that you can't possibly get them wrong; that assumption is usually false.

Organize well:

• Introduce one new concept at a time. Make sure you know, for every part of every slide, which concept it is intended to convey.; Make sure you can describe each concept with a clear, short phrase -- else it's probably more than one concept.
• Introduce concepts in the right order. If concept B depends on concept A, make sure to introduce A first.
• Sometimes it helps to make a directed graph: nodes are the short phrases for concepts, and arrows represent prerequisites. You can then check that your talk is consistent with the graph (i.e., doesn't try to reverse any arrows).
• If there are directed cycles in your graph, you have a problem. Try to refactor your concepts and pull out something that you can introduce before any of the nodes in a cycle, then re-evaluate the dependencies, and repeat until you get a DAG.

Start and end your talk well:

• If possible, put up your title slide while you're being introduced. Then you don't need to read it.
• Make sure the audience knows who you are, especially if you're talking about a paper with multiple authors. You may want to put your name at the bottom of every slide, for people who come in late.
• Make sure you know the first few sentences of your talk by heart. Exact memorization is usually a bad idea for the body of the talk (it sounds stilted), but I find that knowing the first sentence or two helps me get started. (And once I get started I can almost always keep going.)
• Make sure you have an obvious end to your talk, and don't just trail off into silence. Always end with a statement (e.g., “thank you&rdquo) not a question (e.g., “any questions?”).  If you end with a question, the audience doesn't know whether to answer it or applaud, which can be awkward.

• Whenever you can do a little work to save your audience a little work, you should.  E.g., make a better visualization or a better figure, if you think it will improve your audience's ability to understand.  Or, take that huge table of timing results from your paper and translate it into a bar chart that highlights the comparisons you're trying to make.
• View an agreement to give a talk as a commitment.  Don't cancel unless you really, really need to.  If you do have to cancel, give as much notice as you can.
• Plan to show up early.  That way if something goes wrong (miss a bus, projector doesn't work, etc.), you have time to fix it.  Snafus like the above are part of the normal order of the world, and somehow seem to be even more common when you're about to give a talk.  Speakers should therefore expect and plan for them.
• Know your tools.  Make sure you know how to hook your laptop up to a projector, how to operate your presentation software quickly and unobtrusively, how to avoid having instant messages pop up on top of your slides, etc.

Don't waste your own time either.  Don't spend lots of time designing pretty animations, flying text, etc., unless they will actually help audience comprehension and not distract from your talk.  Every second spent animating is a second you don't have for explaining your ideas.