Ch. 7 How to Present
The following is heavily based on the paper:
Rob J Hyndman (2011), Giving a useR! Talk, The R Journal, 3(1), 69–71
Giving a talk/presentation is a balancing act in which you have to try to impart some ideas, provide sufficient background and keep the audience interested, all in a very short period of time. I’ve sat through more than my fair share of bad conference talks. Slides full of equations flashing past quickly, tables containing tiny figures that no-one can read, most of the audience lost on the third slide. Anyone who has attended even one conference will have seen such (bad) presentations.
The problems often stem from confusion about the purpose of the talk. Some speakers clearly think the aim of a talk is to impress the audience with their technical skills, even (or especially) if that means the audience does not understand what they are talking about. Others speakers appear to believe that talks are for those few members of the audience who are working in the same narrow research area – and so no attempt is made to provide an introduction to the topic. Still others see conference talks as an oral version of an academic paper, in all its painful detail.
7.1 The Aim of your Talk
- I like to think of talks/presentations as advertisements for the associated paper.
- The talk is not intended to cover everything you have done, or even to summarize what you have done.
- In giving a talk, I am hoping that:
- everyone in the audience will have a clear idea of what I have been working on.
- some of those in the audience will be motivated to read my paper or put into practice some of my advice.
The tiny tricky details are for the people who read the paper. Generally, there is no point discussing the tiny details of proofs, code or algorithm technicalities. Those who care will explore the details afterwards.
I tend to spend at least half the time going through a motivating example and reviewing the relevant background – most of the audience will need that context in order to understand what the talk is about. In fact, it is reasonable to assume that the audience knows about as much as you did at the start of your work in this area. That is, probably very little. So it is important to spend some time providing background information or you will lose the audience quickly. Do not assume the audience already knows what you have spent long hours learning on your own.
7.2 A Suggested Structure
- Start with a motivating example demonstrating the problem you are trying to solve
- Explain existing approaches to the problem and their weaknesses
- Describe your main contributions
- Show how your ideas solve the problem/example you started with
This structure will not necessarily work for every talk, but it is a good place to start. In particular, beginning with a motivating example is much better than setting up the problem algebraically.
For a 15 minute conference presentation, I divide the time approximately into 3/4/6/2 minute sections. Using this structure, you will have barely started on your own contributions when you are half way through your allocated time. Resist the temptation to trim the first two sections. The audience needs time to absorb the purpose of your work and the context in which it is set.
7.3 Preparing Slides
High quality slides are an important part of a good presentation. I recommend using the beamer package with LATEX.
Avoid distracting slide transitions and dazzling slide themes. You want the audience to focus on your content, not wonder how you implemented some gimmick. Save animation for aiding interpretation.
Use at least a 20-point font so everyone in the room can read your material.
Limit the material on each slide
- Keep the number of words to a minimum.
- Do not include every detail of what you plan to say.
- Keep it simple.
- Resort to text only when illustrations fail you.
- Very often, a table can be replaced with a suitable graphic.
- If you must present tables, only show the essential information. No-one is going to read a slide full of tiny numbers.
- It is easy, but boring, to have bulleted lists summarizing your main points. Instead, use pictures and graphics as much as possible.
- Give only the most necessary mathematical details. When you use equations, define your notation.
Slides are not there to remind you what to say. Use a page of notes for that purpose. The slides are for the audience – make sure everything on your slides is there because it will help the audience understand what you are saying.
Slide numbers.It is useful to add slide numbers so the audience can refer back to specific slides in question time.
On your last slide, give your website or email address for people to contact you if they want to read the paper or just ask a question.
Refine the slides. I spend a lot of time going over my slides looking for ways to improve them. After a presentation is essentially complete, I go through all the slides to see what I can remove – less text is better. I also look for places where I can simplify the presentation, where I can replace text with graphics, and where the titles can be improved. I often spend almost as much time refining the slides as in creating the first version.
Always preview your slides on the computer being used for the talk. You will look foolish if symbols and Greek letters that looked OK on your computer translate into something unreadable on the big screen. Use pdf-slides!
7.4 Keeping to Time
Do not deliver a 30-minute talk in 15 minutes. Nothing irritates an audience more than a rushed presentation. It is like trying to get a drink out of a fire hydrant. Your objective is to engage the audience and have them understand your message. Do not flood them with more than they can absorb.
Cut your material. Present only as much material as can reasonably fit into the allocated time. Generally that means no more than one slide per minute. I tend to use an average of about 0.8 slides per minute of talking. It is helpful to use some slides as time-markers and make sure you are at the relevant slide at the right time.
Never go over time. Keep an eye out for signals from the session chair indicating when you need to conclude. If necessary, be prepared to cut your talk short and finish with a quick summary.
Rehearsing is invaluable. Practise. Out loud. Standing up. Using a data projector. Get colleagues to listen to you, including some who are not knowledgeable on the topic of your talk; they will be able to point out places where you may not come across clearly. After the rehearsal, you may wish to delete some of your material to ensure the talk can be delivered within the allocated time.
Balance the amount of material you present with a reasonable pace of presentation. If you feel rushed when you practise, then you have too much material.
7.5 Giving the Presentation
Confidence. By the time you give the talk, you will have spent enough time preparing your slides and practising your talk that you should feel confident of giving a great presentation.
Talking. Talk at a pace that everybody in the audience can understand. Speak slowly, clearly, and loudly, especially if your English is accented. Speak loudly enough to be easily heard by those sitting in the back row
Engage the audience. Speak to them, not to the projector screen or to your notes. It helps to move around, look at your audience and smile.
Do not apologize
- Never apologize for your slides. Make apologies unnecessary by producing great slides in the first place. Do not say, “I know you can’t see this, but …” If the audience cannot read your slide, there is no point displaying it.
- Do not apologize for incomplete results either. Researchers understand that all research is incomplete. Just present the results and let the audience judge. It is okay to say, “work is on-going”.
When finished, thank the audience for their attention. Stay for the entire session, for the courtesy and benefit of your audience and your co-speakers. Afterwards, be available for people to ask you questions.
My final advise for our last two chapters on writing and presenting:
Everything should be made as simple as possible, but not simpler.
(Quote by Albert Einstein, or some other smart person)