This page provides guidelines for giving an oral presentation at the Chair of Algorithms and Data Structures, in particular for a bachelor's or master's thesis. Please note that these guidelines are work in progress and not yet complete. Whatever is already written here is important, however. Understand that everything that is written here is written for a reason, the reason being that many people, if left to their own devices, do not do this. Hence these guidelines.

Deliverables

The deliverables are decribed on here.

Structure of a presentation

Almost every good presentation has the following three parts, in this order. If you want to deviate from this order, think twice and better ask us first.

1. Problem: explanation and definition
2. Solution: main approach and techniques
3. Evaluation: setup and main results

For oral presentations of a bachelor's or master's thesis, we will make a short break after each part and give the audience the opportunity to ask questions. The reason is that it doesn't make sense to proceed to the next part if something from a previous part is still unclear. The total presentation time for the three parts should be 20 minutes (excluding the time for the breaks and the questions). It is up to you how you divide those 20 minutes between the three parts. As a rule of thumb: 5 minutes for Part 1, 10 minutes for Part 2, 5 minutes for Part 3.

Many presentations have an overview slide in the beginning. It is OK but not necessary to have such a slide. If you have it, the amount of time spent on it should be VERY SHORT. It's a real turn-off to start a presentation with two minutes of vague talk about what is going to come. Better delve right in.

The following subsections provide detailed advice for each of the three parts listed above.

Problem: explanation and definition

It should become 100% clear in this first part of your talk, which problem you are trying to solve. Don't assume that the audience already knows the problem. Maybe they know something about the topic, maybe they don't. But almost no one in your audience will know the exact variant of the problem you considered.

It is almost always best to first explain a problem BY EXAMPLE. Examples should be chosen carefully. They should not be too simple (excluding important aspects of the problem) and they should not be too complex (they should be easy to understand and present in a short time). Sometimes, one well-chosen example is enough. Sometimes, it can be good to have one simple example and one more complex example.

If you have a demo, don't show it at the end of your presentation but in the beginning. A well-done demo is a great way to explain and understand a problem easily. Sometimes it makes sense to first show one or two examples on the slides and then the demo. Sometimes it can make sense to start right away with the demo.

The formal problem definition should be the LAST thing you show in Part 1, not the first. With one or two examples and a demo, 90% of the problem will usually be clear. A formal definition can clear up the remaining 10%. Sometimes, the examples and the demo make the problem so clear that no formal definition is required at all. Anyway, it's always good to have a dedicated slide with a statement of the problem, however formal or informal.

Solution: main approach and techniques

You have worked on your project or thesis for three months or six months or even longer. You have covered a lot of ground. Don't expect to be able to present everything you have done. You have to make a SELECTION. Select the most important ideas and those which gave the biggest improvement. Also make sure that you explain everything that is needed to understand the evaluation in Part 3.

Like for Part 1, the most important advice for Part 2 is to explain BY EXAMPLE first. Again, the example should be well-chosen: not too simple and not too complex. Sometimes it makes sense to take the example(s), which you chose for Part 1 to explain what the problem ist. Sometimes it make sense to take a new example or a slight variation of your example(s) from Part 1.

Visualization is important. Animations can be of great help, especially for complex algorithms or data structures. Nobody understands an algorithm or data structure from an itemized list of (usually vague) text. Neither does anybody understand an algorithm or data structure from throwing code on a slide, unless it is very short and very simple.

Evaluation: setup and main results

Before you show your results, the experimental setup should be 100% clear. In particular, it should be clear which DATASETS you evaluated and how they look like (dimensions, format, an example extract usually helps a lot). The same holds true for the GROUND TRUTH, if applicable for your work.

The MEASURES used in your experimental evaluation should be 100% clear. This holds true, even if you use standard measures like accuracy or precision and recall. Most members of the audience will know what an accuracy or what precision and recall is. But it's usually not clear without explanation how they are defined for your particular problem. For example, precision and recall involves sets (ground truth sets and the sets computed by the evaluated algorithm). What are those sets in your evaluation?

The RESULT TABLES or FIGURES are usually the main part of an evaluation section. Make sure that they have a pleasent layout and are not overloaded. Even if not overloaded, result tables and figures usually contain a lot of information. Make sure that you explain everything that is shown. For example, for a result table, it should be 100% clear what each column and each row stand for. For a figure, it should be 100% clear what's on the x-axis and what's on the y-axis.

General advice

Here is an incomplete list of general advice on the DOs and DONTs of a good presentation:

0. Always come at least 15 minutes before the start of your presentation in order to set up everything and check that everything works. Figure out where is the best spot to stand, so that both you and the audience can see the slides well without any contortions. If you want to show demos involving typing on your latop, make sure that that is possible without hassle, too.

1. Unless you are a pro, rehearse the beginning of your presentation or even learn it by heart. This carries you through the difficult warm-up period in the beginning and gives you confidence for the rest of the talk. There is no need to learn the whole talk by heart, but see the next point.

2. Rehearse what to say for non-trivial explanations. If for whatever reasons an explanation is not good, carry on. Don't give three different bad explanations of the same thing in a row. It does not make things clearer and is a real turn-off, for the audience as well as for yourself. Just tango on.

3. On slides with more complex information (for example, a visualization or animation of an algorithm or a non-trivial results table or figure), always make sure to explain everything that is shown on the slide. If you can't explain something or if you don't have time to explain something, don't show it.

4. For more complex slides, always make sure that you point (with your finger, a laser pointer or the mouse) where you currently are on the slide. Otherwise your audience will not be able to make the connection between what you are saying and what is on the slides.

4. Don't overload your slides. In particular, the amount of text on a slide should always be little. What you say should be in sync with what is on the slides. No one can read a complex slide and simultaneously listen to an explanation which is only loosely connected to the slide.

5. Choose your material wisely and don't pack your talk with too much material so that you have to rush through it. Less is almost always more here. You can always have backup slides for the question session.

6. The typical font size should be 20pt and the absolute minimum (if needed for certain passages) is 18pt.

7. Use colors wisely and sparingly. Reasonable colors are: black, blue, red. Never use colors like yellow or green on your slides, they are essentially invisible on most projectors under typical lighting conditions.