These comments apply to many presentations we’ve seen and address some common mistakes

*Note: don’t copy lecture style and slides - short conference talks are fundamentally different than lectures!*

Type of talk (ML conference) and beware of community culture

Treat it like a talk where you present your own work. Note that this differs from EE or TCS or Stats type talks … The latter tend to like to put more math and see more formulas even though that might not actually help understanding it better … Different cultures.

Mode: give the talk like at a conference. That means: you can’t share slides beforehand or hope people write your notation along - you have to rely on their (limited) memory of previous slides hence → limit the amount of uncommon symbols you introduce!

Hence: do not use the slides in the lecture handouts as an example. They are made with a different purpose in mind (i.e. that you can flip back in the shared presentation/blackboard notes)

Pick the most substantial results to present

Don’t just list a bunch of results just because they’re there and you’ve worked hard to prove them

Only pick the most important results and go into detail in terms of explaining the intuition. In most cases, the main goal is to help the audience understand something interesting, instead of trying to impress them with the breadth of your work. Thinking of audience attention as a scarce resource, you must focus on the main message, as opposed to technical contributions.

Focus on one main insight from the proof that helps to explain and understand a new phenomenon. The aim is that the audience thinks this is such an interesting new intuitively graspable insight they might want to read through details themselves afterwards. And use the intuition in future papers (and hence cite you ;))

For the specific case of the class presentation: Please break free from authors notations, their way to present the results etc. Imagine a friend came to you with the results and you are now supposed to sell the story in the best way possible, thinking about writing/telling the story

**from scratch**and examining their choice to present things**critically**.

Main message teaser

The problem must be clearly stated in the first few slides (1-2). You must clarify (1) what is the problem? and, (2) why is it important? The audience is not familiar with the paper and topic as you are, so you must avoid technical terms as much as possible.

After motivating the problem, illustrate main results with figures / drawings (e.g. plots, if paper doesn’t have, produce some) and easy language

**before**introducing any mathematical notation (i.e. to present setting formally) and stating formal theoremsWhat’s the most surprising / intriguing result

*in words*and why?How is it related to practice?

Put your paper in the context of existing literature

*that tackles the same problem*perhaps in different ways / with different assumptionsIf you present a computer vision paper do not discuss the imagenet paper. The literature that is relevant to

*motivate*the problem does not need to be mentioned in detail unless noone has tackled the problem beforeInstead, discuss other papers that have tackled the problem! How is this paper different? People need to know in the beginning what

*your paper’s novel contribution*is. But also during the presentationLiterature review: if you plan to cover more than four papers in the review, you may add each paper to a topic cluster and explain the topic instead. This way it’s more time efficient, and it’s also easier for the audience to get familiar with the concepts.

After the motivation and teaser: Give them a heads up

After the audience understood what problem you aim to solve, give them an outline on what to expect in your talk (see lectures). Some go through the outline first - however, if the audience doesn’t know any of the terms in the outline they won’t be able to remember the outline well

Sometimes in the talk it’s nice to remind them where in the outline you currently are

Only introduce notation right before you use it (e.g. in theorem), limit number of used math symbols and instead use figures wherever reasonable

Think about the attention of (any) audience as a (quite) limited budget

Think carefully which symbols and notations are the most necessary to maximize learning experience, i.e. minimize the number of symbols you use!

Instead use visuals like plots / diagrams whenever possible. Much easier to remember and to connect different points. But go through them slowly

However whatever symbols you have to use, make sure the audience knows at every slide what every symbol means and do not use the same symbol for different quantities! (nice side-effect: automatically limits the number of symbols you will use)

in theorems, do not aim for perfect rigor but for the ability to be intuitively understood (hide constants and things that the audience cannot make sense of in the one minute you’re on that slide) optimize tradeoff between amount of rigorous info vs. intuition.

Connect to people’s existing knowledge

Refer to previous knowledge (in our case: lectures) when you use a concept we covered in class. Don’t pretend it’s something we’ve never heard of.

People learn much better when connection to their background is clear and hence follow much better.

Use same notation as in lecture where possible (even if that means that it’s different from the paper (whp it will be))

How to present a theorem: in a modular way

After theorem statement, give intuition, potentially illustrate with examples what it is claiming

Filter the strong assumptions from the weak. Also try to always discuss the implications of making those assumptions on the applicability of the result

proof depends on following key ideas (lemmas) 1,2,3, which are insightful and intuitive (give rise to potential new proofs)

If the lemmas have key insights beyond algebra that are crucial to understand where the surprise in the theorem comes from, add the proofs of lemmas afterwards

*Note: This is mainly repeating https://www.youtube.com/watch?v=meBXuTIPJQk*

Slide flow

Make sure the reader always knows how each slide is connected to previous slide and to the main point of the presentation

e.g. is this now just setting it up, the actual mathematical formulation of main point, interesting extensions for different assumptions…, empirical finding?

Connect slides with a good transition (you can use last line to make transition explicit), e.g.:

`Caveat: x, Next slide: y`

Summarize slide / table / plot / theorem message

Each slide should convey one message, summarizable in a one line slide title

Don’t

*number*figures / tables / theorems which usually happens when you blindly copy from papers. Instead, summarize the main message in few words in brackets.Don’t refer to sections, claims etc from the paper by their number (e.g. “in section 7 blabla”)

Slide style

Only put things (figures, labels etc.) on the slides you will refer to verbally

That will automatically cut down on slide content

Don’t make slides too full (max 4 bullet points-ish)

Write bullet points (see lectures)

NEVER write a full a paragraph

nor full sentence

one conceptual point per line!

*Absolutely*use animations whenever possibleReveal important blocks one at a time on one slide, e.g. different bullet points, theorems after notation, or proof sketch after going through the theorem. General rule: The less connected the points are, the more inclined you should be to reveal one at a time

That makes sure the audience is not wondering about something on the slide you are not talking about, hence losing their attention

For some more sophisticated study on how to exploit text on slides with what you say, please watch https://www.youtube.com/watch?v=meBXuTIPJQk