Presentation smells: How not to prepare your conference presentation

Recently, I was in Austin, Texas to attend ICSE (International Conference on Software Engineering) and MSR (Mining Software Repositories) conferences. The authors presented excellent papers on a variety of topics concerning software engineering. Despite their excellent technical content, I was discontented by the presentation skills exhibited by some of the authors. It’s not only the students, but even some of the experienced researchers gave not so exciting presentations.

Preparing for an effective presentation and presenting it well on a large forum is a very important activity in the lifespan of a research idea. Therefore, every research student should learn how to create and present effective presentations.

So, how can we become effective presenters? Well… there are many useful resources available such as Slide:ology, Presentation Patterns, The Elements of Computing Style, and Presentation Zen on preparing good presentations and effectively delivering them. In addition, I have put together a set of presentation smells based on my understanding. Each presentation has two major aspects: slides and delivery. In the rest of the article, I describe presentation smells concerning the first part (slides) that every presenter should avoid.

1. Text hell

A presentation is not a document nor a teleprompter; hence, don’t try to stuff all the information in words. If a slide contains a lot of text, your audience will try to read the text and will not bother what you are speaking. Slides are for defining the flow and providing visual information such as images and videos; thus, use it in the spirit and not otherwise.

2. Color-mania

Slide design is not a competition where slides with maximum colors used will win. A human mind takes some time to identify and process the colors; therefore, simplify your slides and avoid multi-color text so that the audience pay attention to content and not to the colors. Use preferably one (or maximum two) colors for the text in a slide and use them consistently throughout your presentation. Also, pay attention to the background color and contrast; avoid multicolor background and make sure that foreground color of your slides is contrasting with slide’s background color.

3. Brother of the bride

In many cultures, brother of the bride has many responsibilities at the time of his sister’s marriage. Don’t make your slides look like such a brother. In other words, follow single responsibility principle and put one concept, idea, or thought in a slide.

4. BYOB (Bring Your Own Binocular)

The text (or image) that you put on your slides must be readable from the back of the room where you are going to present. The audience does not carry binoculars; thus, you must not pretend the same.

5. HiPU (Highly Paid but Useless) headers

Headers get the highest attention because of their size. In many situations, slide headers are verbose and do not convey additional useful information. Avoid headers in such cases, or reduce their size.

6. Secretary of HiPU

A line under the slide headers is analogous to a secretary of HiPU. Do not underline the slide header. It populates the slide with unnecessary noise. In fact, underlines must be avoided not only in headers but also in the body text.

7. Do you know who I am

The title slide may contain affiliation about the contributors and presenter; however, repeating this information (in the form of university/company name or logo) at the bottom (or top) of every slide is unnecessary and annoying.

8. Bullet, [sub-]bullet, [sub-sub-]bullet

One level of bullets in a slide is preferred. Use the second level of bullets only when it is really necessary. Third-level bullets must be avoided.

9. It’s Las Vegas

Animations must be used only where they make sense. Over usage of animations with a lot of moving objects distract the audience and thus, must be avoided.

10. Chaotic stylist

All the slides in a presentation must follow a single style consistently. The style includes text size and color for both body text and headers, color, width, and drawing pattern of shapes, and border style and shadow of image objects. Inconsistency shows recklessness of the presenter and thus, must be avoided.

11. Stung by spell-bee

Making a spelling mistake is analogous to committing a crime. Spell-checkers are available on each presentation preparing software, so there is no excuse for making spelling mistakes. Each presentation must go through a spell-checker to avoid unnecessary embarrassment.

12. The devil of details

Do not try to explain the nitty-gritty of your method or idea in a short presentation. Often, the short time is not enough to allow the presenter to go in the details. An attempt to quickly cover the details will result in the losing attention of the audience. Abstract the idea, simply complex figures, and use metaphors to communicate your ideas effectively.

If you are wondering what a great talk looks like (from both slides as well as delivery perspective), consider watching talks by Martin Fowler, Garr Reynolds, or David JP Phillips.

Please note that these are just guidelines to create better presentations. It’s not necessarily a bad thing if you cannot follow any of the above guidelines especially when you have an appropriate rationale for not doing so.

ToolsI have developed a tool slideQ to detect these presentation smells. It is open-source under a liberal license; feel free to clone, modify, and use. 🙂




[Originally posted on XRDS]

Author: Tushar

Tushar Sharma is a software engineering researcher, developer, and author. He is currently a Research Scientist at Siemens Corporate Technology, Charlotte, USA. The topics related to software design and architecture, refactoring, software quality (specifically code and design quality), and technical debt define his career interests. He earned PhD from Athens University of Economics and Business, Athens, Greece with specialization in software engineering in May 2019. Earlier, he obtained an MS in Computer Science from the Indian Institute of Technology-Madras, Chennai, India. His professional experience includes working with Siemens Research and Technology Center, Bangalore, India for more than seven years (2008-2015). He co-authored the book Refactoring for Software Design Smells: Managing Technical Debt and two Oracle Java certification books. He has founded and developed Designite which is a software design quality assessment tool used by many practitioners and researchers worldwide. He is an IEEE Senior Member.