Table of Contents
At some point in your life you're bound to be in a position where you need to present on a subject. While books on presentations abound, none are really aimed at really technical subjects, nor really technical presenters.
Some of the normal rules don't apply to us. We like numbers. We like complicated graphs, as long as they are presented well. We need less dumbing down, in fact, we distrust stuff that is too glib.
So, this document is for the geek who needs to do an ungeeky thing: present to a crowd, and do so well.
I assume the reader will want to use his technical and analytical knowledge to give a great presentation. Most technical people are more than smart enough, but it takes some effort to use that high-octane brain for other things than doing actual work!
First we'll get down to the real basics.
You are in luck, as your audience is going to be technical, they'll see through that. Do make sure you do the easy things right: speak out loud, look at your audience, prepare well, but it doesn't matter that you aren't a natural presenter, or at least, not too much.
Just make sure you have something real and interesting to present, and the superficial stuff will matter less. Many presentations are relatively content-free and need a flashy presenter, but this doesn't apply to us.
The ultimate question, but it makes sense to ask. It is so big a question it is easy to overlook. Why are you going to present? It is very much worth your while to really work this out. Good answers are “To tell people how they can use my/our cool technology to improve their lives”, “To engage people and convince them to join my cool project”, “To get people's opinion on where my project should be going”.
Generally bad reasons to present are things like “To tell people about the progress I've made”, “Because my boss told me ”, “To get into this conference for free”.
Note that the first answer, a progress update, might be appropriate if that is what you were asked to do, or if you are pretty sure your audience is well aware of your progress up to some unspecified point of time in the past.
This is about as important as the big 'why' question, but sometimes harder to answer. You sometimes need to figure it out yourself as it depends on the conference, the theme, the track you'll be in etc etc.
Try to get as good an idea as possible. Will they be kernel people? End-users? Application developers? Quality Assurance? Support? Or technical managers, decision makers? 'Who?' changes what you should, or can, tell people, so it is important.
Note that you can influence this somewhat with the choice of your title. If you want in-depth people, make sure your title, abstract or proposal indicate that you'll be going in-depth, and people intersted in such a presentation will come to listen.
Anyhow, try to get as good an indication of your audience as you can get. If you're comfortable with it, you might simply ask at the start of your presentation and shift emphasis accordingly.
The “What?” question ties in closely to the “Why?” question. The relation is that you need to figure out What to tell so you satisfy the reason (Why) you wanted to give a presentation in the first place.
So, what do you want to tell? You've probably done, or discovered, a lot of interesting things. Far too much to mention all of them. So your job is mostly to select.
The way I recommend you go about this is to first write an outline of what you are going to say.
Make an outline of your presentation, in other words, something like: “First I'm going to explain that project A is important, because it allows you to do X, Y and Z. Then I'll show you how you can do X, Y and Z, and how well project A does those things. Then, I'll explain how we could do U, V and W as well, and how useful that would be, but that more coders are needed. Finally I'll explain how to join in.”
This outline would fit in with one of the “Why?” questions mentioned above.
Making an outline helps you 'place' each slide, and make sure you are presenting a coherent story. Don't even attempt to present without having an outline! It need not be as self-contained as the one above, it could well have multiple parts.
It pays to spend quite some time on the outline, but make sure you've answered the 'why', and 'who' questions first!
Now that you have the proper outline (have you written it down?), it is time to implement it. Note that I haven't mentioned slides before, and for good reason. Your presentation is not the sum of your slides! There'd be no reason to have you around otherwise, people could just browse your work online.
So why do we have slides? Slides have some uses:
To display pictures or schematics that enhance the spoken word
To provide context for the presentation, for when attention drifts - the slide can help people back in the sadle
To remind you what you should say next
When creating slides, keep these points in mind.
The first slide should generally be who you are, and the title of your presentation.
It helps to be honest: as the second slide, tell people what you are going to tell them. This need not be an exact copy of your outline, which may be a bit too honest, but it should be close.
When trying to transfer information, one of the most important things is to make sure the recipient is able to figure out the 'place' of everything you are saying.
Take this sentence from a Xen HOWTO:
With d-i/xen you can use debian-installer to install a machine running Xen, then in the domain0 linux instance, you can use debian-installer to install standard recipes.
The above implies knowledge of what is meant by 'd-i', 'domain0', 'instance' and 'recipe'. If there is some doubt, it is very hard to understand this sentence, and even harder to understand following ones that presume comprehension of what came before.
So it pays to spend time on making sure the relation between important concepts is clear. For the sentence above, something like this would help tremendously:
- Xen
A program that allows multiple operating systems ('instances') to run simultaneously on one computer.
- d-i
The debian-installer, d-i/xen is a version of the debian-installer that deals with xen. The debian-installer installs a Debian image.
- domain0
When Xen runs, it there is one master 'domain', the operating system that talks directly to the hardware, sharing its resources with other operating system images that may be running.
- recipe
A script executed by the debian-installer to install certain functionality.
Now read the initial sentence again and see how it makes perfect sense. The conclusion you should draw from this is that it is highly important to define concepts, and their relations, first.
With the concepts explained, you can start working on implementing the outline you wrote earlier. Do not hesitate to add some more 'concept' slides in between when advancing to new subjects though!
Some general slides rules:
Make sure they don't contain too much information. This makes them hard to read, and less suitable as 'backdrop' to your verbal presentation.
Use bullet-points to separate information - the slide should not be like a page out of a book!
Only use 'fancy' things like animation when they actually make sense. It is useful to illustrate packets moving from A to B, but don't use animation 'because you can' - it detracts attention from your real content.
Graphs, tables, diagrams. These are all good things but make sure everybody can understand them. What units are on the axes? What do they represent? What are the columns of a table? What do the boxes in a diagram denote?
When making slides, pay attention to transitions. Do they make sense? Is an intervening slide necessary, or an explicit bridge?
Ok, this is hard. You need to practice. And yes, this means getting in front of a mirror, and actually holding your presentation. 45 minutes of mumbling. If you can, try to get a real audience to test against. I know how silly it sounds but it works *so* well to work the kinks out of your presentation.
![[Note]](note.png) | Note |
|---|---|
Do as I say, don't do as I do! My presentation at the Ottawa Linux Symposium 2005 was unpracticed, and it showed! | |
One important thing you'll learn is how long your presentation will take. It is advised to keep a certain margin - it is no problem for a 1 hour presentation to end after 45 minutes, as you might fill up the slack with questions, answers or general discussion. Overruning your timeslot is lots worse!
Most of my presentations have some kind of gauge for me to see how far I am. At Linux Kongress 2001 I even had a wicked Perl script that displayed in a corner how far behind/ahead I was, based on the 'weight' of each slide. This is a nice thing to have.
It is entirely possible to finish your presentation in half the time you'd think it would take, so pay attention!
Depending on your presentation style, it might pay to have one page filled with things you should think of. Do not ever write out your entire presentation - it doesn't work. But it is very useful to have a list of things that should be mentioned, or things you tend to forget.
Things go wrong. And when presenting, Murphy is in force with double strength. So you need to be prepared. If possible, make sure you have at least 15 minutes to make your laptop and the beamer work together.
To test, connect a regular CRT or TFT screen to your laptop, and configure things to work at 1024x768 resolution, using a low refresh rate (65Hz or so). Verify that you are able to display on both your own screen as on the external one.
A trick to achieve this is to boot with the external screen attached. Many laptops also have a button to initiate external display.
Some conferences have decided that this is all too much hassle and require presenters to provide their presentation on PDF. This is a very wise move, as it will allow you to present from a known-good configuration.
When worst comes to worst, make sure you have your presentation with you on a USB memory stick, as a PDF. You'll generally be able to find a laptop that does work, and almost all laptops have software to display a PDF.
Also make sure your laptop is in a mode where it will not suddenly decide to switch to standby, or hibernate! One easy way to prevent this is to make sure it is powered and not running from battery.
There are some very geeky tools out there (MagicPoint), but these days Openoffice Present has all the features one would ever need. There is also Kpresenter. Openoffice Present has been verified to produce pretty PDFs and comes recommended.
When going to an Open Source conference, and you decide to present using a non-Open Source platform, make VERY sure nobody notices!
Be relaxed, make sure you turn up real early. Figure out where you are expected to be a long time in advance.
| Note |
|---|---|
At OLS 2005, room A was on the third floor, B and C on the first floor and D on the second one. And even though this was all made clear using signs, when arriving at the last minute, you'd be in a good position to get lost. | |
At the earliest opportunity, start installing your laptop, or transferring your presentation to the designated computer. If there is a microphone that needs to be connected, get it so, but make sure it is on mute if you are still talking to people!
As soon as possible, make the screen display the title slide of your presentation, which will allow people browsing rooms to verify if they are in the right one, or (if you have a good title) to become captivated and decide to join your presentation instead if they were in the wrong one!
When ready, relax. Read your notes. When you start your presentation, always ask if everybody can understand you, especially in the back. If you need to speak up, be sure to continue doing so until the end of the presentation!
This is purely superficial, but things look lots better if you pick a few people in the audience, and alternatingly look at them. This makes the audience feel connected to you, and makes them pay more attention.
Don't talk too fast, nor too slow! Check yourself every once in a while, you can generally tell if you are rushing or slacking.
During the meeting, pay attention to any timing markers you have recalled. This might be as simple as discovering you're on slide 20 of 40 after only 10 minutes. If this happens, slow down and be more verbose. You can lose 20 seconds easily by drinking a glass of water - if you want to.
During your presentation, try to see if your audience is still interested, or losing focus. I find that it works well to query every once in a while if everything is still clear. This makes special sense if you have just shown a complicated slide.
An easy way to check if everybody is still paying attention is to make a funny remark every once in a while, and see if people catch it. If not, try to be clearer, or make your remarks funnier :-)