Giving a useR! Talk

Giving a UseR! talk at the the international R user conference is a balancing act in which you have to try to impart some new 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 these examples and more.

1 What is the aim of the talk?

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.

Instead, I like to think of conference talks as advertisements for the associated paper or R package, or shared wisdom gained through valuable experience. 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 (1) everyone in the audience will have a clear idea of what I have been working on; and (2) some of those in the audience will be motivated to read my paper, download the associated R package, or put into practice some of my advice.

These aims mean that I never bother with proofs or derivations — they are for the people who read the paper. Similarly, there is no point discussing the internals of R code or algorithm technicalities. Those who care will explore the details afterwards.

Instead, 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.

2 Consider the context

For a useR! talk, there is the additional challenge of getting the right balance of code, technical and application detail. The appropriate mix depends on the session.

If you are giving a kaleidoscope talk (for a wide audience), you need to make a particular effort to make your talk accessible, keeping examples simple and minimising technical detail. Speakers in focus sessions should consider what other talks are in their session in order to determine how specialised the audience is likely to be (e.g., people at a high performance computing session are probably comfortable with technical details, but those at a session on ecology are likely to be more interested in the application detail.)

Looking at some related talks from previous years can be useful. Many talks from previous useR! conferences can be found on the conference websites (see http://www.r-project.org/conferences.html for links).

3 A suggested structure

I recommend the following structure for a conference talk:

1. Start with a motivating example demonstrating the problem you are trying to solve;

2. Explain existing approaches to the problem and their weaknesses;

3. Describe your main contributions;

4. 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.

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.

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. If several people in your research group are attending the same conference, get together beforehand and practice your talks to each other. Make such rehearsals as realistic as possible and time them. 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. Budget your time to take a minute or two less than your maximum allotment.

5 Preparing slides

High quality slides are an important part of a good presentation. I recommend using the beamer package with LaTeX. MS-Powerpoint is also popular, but it makes it much harder to format mathematical symbols and equations nicely.

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. (The default font size in beamer is generally too small — use a 14pt font in beamer which is equivalent to 23pt on the screen.) Similarly, view your slides at 50% on screen to check that code and figures are legible. Unreadable material is worse than useless — it inspires a negative attitude by the audience to your work and, ultimately, to you. Many R users are near-sighted; do not make it any harder for them.

Limit the material on each slide, keeping the number of words to a minimum. Do not include every detail of what you plan to say. Keep it simple. It is easy, but boring, to have bulleted lists summarizing your main points. Instead, use pictures and graphics as much as possible. Resort to text only when illustrations fail you.

If you must present tables, only show the essential information. No-one is going to read a slide full of tiny numbers, let alone absorb the information. Very often, a table can be replaced with a suitable graphic.

Give only the most necessary mathematical details. People not working in the research area can find equations difficult to follow as part of a rapidly delivered presentation. When you do need to use equations, define your notation.

Avoid showing too much R code. Trim it back to the bare minimum so the audience can focus on the essential details. Use different colours to clearly distinguish R code from output.

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.

On your last slide, give your website or email address for people to contact you if they want to read the paper or download your R code or just ask a question.

It is useful to add slide numbers so the audience can refer back to specific slides in question time.

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. This is much more common if you use MS-Powerpoint as the fonts may not be embedded in the document and so equations lose important symbols.

6 Giving the presentation

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.

At the conference, make sure you talk to the session chair beforehand so they are aware of who you are. Arrive at the meeting room 10 minutes before the session begins to take care of last-minute details.

Talk at a pace that everybody in the audience can understand. Speak slowly, clearly, and loudly, especially if your English is heavily 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.

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.

Note

This article is converted from a Legacy LaTeX article using the texor package. The pdf version is the official version. To report a problem with the html, refer to CONTRIBUTE on the R Journal homepage.