These are not very organized, sometimes repetitive, and sometimes contradictory pieces of advice. Good and great talks come in many different forms, and you don’t have to comform to any format. Feel free to break any rules that I (or others) lay down. But at least think about what choices you are making, and why.
The current clustering of the suggestions is a bit clumsy, sorry: I will fix these when I get some time.
Tailor your abstact to the audience. Don’t just copy your paper abstract over to the talk abstract. The audiences are different:
Paper readers are usually experts in your area, talks are often for a broader audience. Make the audience interested in what you are going to say — there is no point in preparing a good talk if people don’t come to your talk because the abstract was off-putting.
Also, the abstract is often read in an email, or on a flyer next to the elevator. The amount of attention they will spend on your abstract is much less. Cut to the chase.
Explain what problem are you solving. Why should the audience be interested in it? Also, you probably should not list all your results, or use a ton of jargon in the talk abstract. Try to not have latex in the abstract, if at all possible.
Be empathetic. Know your audience. Why should they care about what you’re telling them? What do they know? What would they like to know?
Give the audience what they came for. (Question: what did they come for? If you don’t know the answer, please try harder. :) ) E.g., don’t spend time giving them definitions of basic things they know. It’s OK to remind them of important concepts they may not use every day, so tell them that you’re reminding them.
Try to give people something to take away from the talk. A nice nugget, a nice idea, a technique. Something. Anything they can file away. If you can give two, that is even better. Three may be pushing it. :) Gian-Carlo Rota’s advice: “Give them something to take home.”
You are telling a story. Always think of what the story is. Each slide should advance the story in some way. If needed, give a road-map slide, if the story is complicated and people might forget where we’re doing. Then stick to the roadmap.
BTW, I am not a big fan of road-map slides, but they have their uses. If you feel it will help, by all means use it.
Tell them what you will tell them. THEN tell them what you want to tell them. AND THEN tell them what you have just told them. You don’t need to belabor the points, it should appear natural.
E.g., you mention the theorem statement at the start of the talk. Then, 20 minutes later, you show them the theorem statement again (maybe a simplified version, maybe a special case, maybe even a generalized version), and follow it with the proof. When that finishes, you can say: this completes the proof of Theorem 1 (showing the statement again). [You can vary this general approach in many ways.]
Practice your talk before giving it to the speaking club. Don’t go through the pain of having yr talk torn apart by 3-4 people if you dont have the time to practice it (at least once, maybe more, depends on how prepared you feel).
If you cannot practice your talk in front of others, practice it by yourself and tape it. Watch it and critique your performance. Repeat if necessary. (Do this for all your talks until you are confident and comfortable giving talks.)
Don’t claim something that you cannot justify either in the talk, or soon after the talk.
If you forget something (a proof, a reference), that’s fine. Acknowledge it, apologize and move on. Later, after the talk, figure out who asked the question and get the answer to them, if at all possible.
Anticipate, anticipate, anticipate: if you’re worried something may be misinterpreted, rest assured that it will. Put yourself in others’ shoes, look at your talk from the perspective of the audience. This is not easy, and I am not sure I know how to do this well, but I try.
Define the problem clearly. Everyone should understand the problem.
Give an example instance, if possible. If the audience does not understand the problem you are talking about, your talk has FAILED in its first basic objective.
Think about: why should the audience care about the problem? Not always necessary if you are talking to the choir (i.e., if this is a standard problem in the field). E.g., if you are talking to theorists, explaining why TSP and Max-Cut are important is not only unnecessary, it is a waste of others’ time. But if the talk is for a broader audience, you may want to explain it.
State your theorem/results as early as possible, after the problem is clear. So if people zone out really early, at least they know the problem and the result.
If needed, this result could be an informal version of the full result, without all the bells and whistles. [Especially if you need notation to give the full result.]
Define terms that may not be common knowledge. use as little specialized jargon as possible. Define jargon when you do.
If you use some concepts that the audience may not remember, do remind them. especially if these are crucial. Give examples if needed. (Good combo when it works: remind them using examples.)
This is particularly true for notation: when you introduce some notation, remind them when you use it again. (Until the notation has cemented in the minds of the audience.)
Use the power of pauses. When you are giving an important definition, your main theorem, the crucial point of the lecture, pause for a second. Repeat this important bit of information, if the silence seems awkward.
Do not introduce ideas that you do not need. mention them in the related work section if necessary.
Avoid unnecessary words on slides. I often drop articles (a/an/the). And I abbrev words when unambiguous. Visual fatigue is a real thing, the less you ask people to read the better.
Similar for math: you can hide lower order terms, as long as you make it clear you’re doing so.
Say the previous bound was O((n2/3log2n)/ε2log(1/δ)). Your focus is on the n2/3 part, which you improve to n1/2, but you lose another log n factor and another factor of ε. Does the audience need to know about these lower-level details all through the talk? I would show the whole math expression once, with the n2/3 emphasized (using color), then say “I’m going to focus on this part, please don’t worry about the rest for now”, hide the rest, and proceed talking about n2/3 versus n1/2. At the very end, I would show the final runtime, point out the extra log loss (not a big deal). The extra loss of ε could be a big deal, so maybe you want to keep it around. It’s your talk and you should choose. But realize, it’s the audience’s attention span, and it may run out sooner than you like.
When giving details of your result: Explain the simplest interesting result in detail, and then generalize. If you are talking about sparse graphs, and the result is interesting for a tree, first talk about that. You can indicate later what ideas are needed for the general result.
Give enough background and history.
is the problem new? what has been done before?
is there a “strawman” solution? a “cheap” solution? why does it work/not work? why is your solution better? This gets the audience involved…
Do not spend time on unnecessary background and history. Do not describe the 27 (or even 5) previous results, if knowing these is not essential to understand your work.
Do not show a lot of stuff on the slide and say: “don’t bother with all this, just read Line 7.” Remove all the stuff you don’t need them to read. Not doing this suggests laziness on your part.
Try to make the notation intuitive. If d and D are two distances, it will help the audience if d is the smaller of the two. Or if the function is called f and the gadget is called g and budget is B, etc., and if ε is small, and M is large.
If you claim something is counter-intuitive, make sure it is clear why the converse was “intuitive”.
Don’t go over the time allotted. Clearly categorize the stuff you can skip over, if need be.
Prepare stuff to speak about when you have more time. This need not be in the form of more slides; you can just speak for longer.
Don’t just speak faster to cover the material within the alloted time. It’s not a race. Your goal is for the people to understand, not to get through the slides.
If you change context–say it’s a new problem, a new assumption, a new proof, anything—make sure the audience realizes it. Pause for a second. Have a transition sentence.
Try not to introduce too many problems in a talk. One or two is ideal, but the audience may find it tiring to juggle multiple problems. Especially if these are problems they are not familiar with.
Try not to introduce a new problem late in the talk. Especially if you have already started getting into details (e.g., you are deep in a proof, etc.). Like a good cook, get everything in place before you start cooking.
Label things that you may want to point to. it is easier to say ‘consider the distance from (pointing at a) “a” to (pointing at b) “b”’ rather than to say “… from there to there…”. Especially if you have a weak laser pointer.
Partially opposite advice: dont label things unnecessarily.
Final point: putting animation to full use, you can label and unlabel things as and when required.
A picture is worth a thousand words. (Usually.) Put pictures as small examples. Give a example picture for definitions, if you can. give a small example of your algorithm.
In general, if there is a picture that people should have in mind, make sure you flash that picture. then they will have the same picture in mind as the one you have – makes life simpler.
Sometimes this is a bit tricky: the real picture is complicated, and the “simpler” picture is sometimes misleading. In that case, you just have to spend more time refining the talk till you have a good picture, or a really good explanation. Sorry.
A picture is worth a thousand words – except when it requires a thousand words to explain.
Make sure that “proofs by picture”, and perhaps more importantly, “definitions by picture” are well thought out. If the audience do not understand the definition, you have lost them.
Use colors. Use color variations for math, emphasis, etc.
Use colors consistently.
Do not use too many colors.
Graphs/plots: clearly mark your axes. Spend enough time on the graphs: what do the graphs mean? Are the results expected or unexpected? why?
Plots and figures: make the lines thick; make pictures clean. If possible, use color and animation to make sure things are clearly visible and discernable.
Final slide: don’t end with a slide that only says “Thanks” or “Questions” and nothing else. Instead, end with a slide with the main take-aways and/or open directions and/or pointers to the paper, etc. Which may be your next-to-last slide, anyways. (Maybe you can write “Thanks” at the bottom.)
Citations: audience-dependent. If you and the audience know the people in the citations, you can abbreviate refs, else it is only fair to give people’s full names.
If the audience has no clue about the people in the area, don’t overwhelm them by slowly going over a list of citations of papers by people they dont know. In fact, going over a long list of citations is a terrible idea in almost all contexts.
You must give credit where credit is due. Give the most relevant citations. If the problem has been studied before, maybe the first, the latest, the most closely related?
Citations are important for the audience to understand the problem context. (Is this a niche problem? Which scientific communities study it? Who cares about it?) You can probably answer these questions by choosing a small representative set of citations. Very useful for broader audience talks, for job talks, even for Theory Lunch.
Fonts: use thicker fonts – fonts with thin segments strain the eyes. People tend to give up.
Don’t use too many fonts.
Also, use technology to your advantage. People will not try to read a complicated page of text. Introduce text as and when you need it.
If the same text/picture appears on consecutive slides, ensure it appears in the same place on both slides. Else the audience will spend energy figuring out what shifted and changed. More visual fatigue.
Complicated transitions between slides (scroll in from the left, etc.) can be distracting. Especially if you are bringing in the text on a slide in parts: people will lose their position on the page.
Don’t stand two yards away from the projected image and point at the screen using a weak laser pointer (or worse, vaguely point with your hand). If you can reach the image, please walk over to the image instead. Or get yourself a good laser pointer with a good red/green dot.
I carry a metal extendible pointer in my bag, but I am old-school in that respect.
Remember that when you’re pointing at your laptop screen, we cannot see where you are pointing. :)
Keep a piece of chalk or a marker handy. Use the board if needed.
Use the tablet feature on your computer to point at things, and to highlight them. Or just the little arrow to point at locations on the slide, if all else fails.