-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathadvice.html
executable file
·181 lines (154 loc) · 9.69 KB
/
advice.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link rel="SHORTCUT ICON" href="CarnegieMellon_logo.gif">
<title>Advice for Technical Speaking</title>
</head>
<body bgcolor = "#ffcc99">
<table bgcolor = "#ffffff" width = "70%" align = "center" border="0" cellpadding = "15">
<tr>
<td>
<h3>Advice for technical speaking</h3>
<h5>Shamelessly pilfered from <a
href="http://www.cs.cmu.edu/~ggordon/speaking-advice.html">Geoff
Gordon's advice page</a></h5>
When you hear a talk - a good one or a bad one! - think about the
presentation as well as the content. Copy what works, and avoid what
doesn't. If you see a great talk, examine it and try to figure out
what makes it great. If you see a poor talk, examine it and ask
yourself if you might make the same mistakes. Some of the most common
mistakes are below, but people are really quite creative in coming up
with new mistakes, so don't assume this list is complete!<p>
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.<p>
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.<p>
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.<p>
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.<p>
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.<p>
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 <b>not</b> 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.)<p>
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 <it>one</it> specific person I know well in
mind - and think about what I would say to engage and inform him or
her specifically.<p>
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:
<UL>
<LI> Don't ask people to listen to one thing and read another at the
same time. <LI> Don't ask people to remember an equation or
definition 5 slides later: just put up a copy when you refer to it.
<LI> 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.
<LI> 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”).
<LI> 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.
</UL>
<p>
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.<p>
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.
<ul>
<li> 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.
<li> 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.
</ul>
<p>
Organize well:
<ul>
<li> 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.
<li> Introduce concepts in the right order. If concept B depends on concept A, make sure to introduce A first.
<li> 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).
<li> 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.
</ul>
<p>
Start and end your talk well:
<ul>
<li> If possible, put up your title slide while you're being introduced. Then you don't need to read it.
<li> 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.
<li> 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.)
<li> 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.
</ul>
Audiences hate to have their time wasted. So:
<ul>
<li> 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.
<li> 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.
<li> 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.
<li> 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.
</ul>
<p>
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.<p>
</td>
</tr>
</table>
<hr>
<address><a href="mailto:wcohen@ROCKY"></a></address>
<!-- Created: Mon Jan 03 15:12:34 Eastern Standard Time 2011 -->
<!-- hhmts start -->
Last modified: Mon Jan 03 16:09:28 Eastern Standard Time 2011
<!-- hhmts end -->
</body>
</html>