Stuff (not) to do in presentations

Disclaimer: Like everything else that I write, I don't claim any special knowledge, or indeed any knowledge at all of the things I write about. They may be completely foundationless rubbish. They probably are! On the other hand, since most of these things are based on my own reactions to god-awful presentations or just things that I've seen done badly (possibly by myself), maybe there is something to them.

Other info

The best introduction to giving talks that I've seen is Matt Dominus' "Conference Judo" talk. It's full of good advice, even though the exact context (3 hour software tutorials) is unlikely to apply to most people. Don't let that put you off --- it's all good stuff. Best advice point in a nutshell: public speaking is a performance, so aim for an entertaining performance.

An excellent and amusing document is Till Tantau's extensive documentation for his Beamer LaTeX class. As well as entertainingly describing the superb Beamer package, this contains much excellent information on giving good presentations. See the Beamer web page for more details. Till's other amazing LaTeX package, PGF/TikZ also comes with excellent advisory documentation on the use and design of graphics and figures.

Another good collection of information to bear in mind, though not presentation specific, is the World Wide Web Consortium's (W3C) guide to accessibility of information. It's linked to from

How to make the slides?

Methods for preparing presentations include: OpenOffice Impress, MS PowerPoint, LaTeX (Beamer, Prosper, FoilTeX...), HTML, DocBook... and there's always pen and acetate / chalk and talk etc., though they're less useful since your listeners only get one chance to see your talk. Personally, I find the compactness and programmability of LaTeX irresistable: you don't get quite the same freedom of layout as with PowerPoint-type tools, but the output looks good, the files are small and PDF output is anyway the most sensible format. It's hard in LaTeX to put images in random places, use silly fonts or to overlay arrows and things in confusing ways --- I think those are probably features rather than limitations. In my opinion, Beamer is by some way the best presentation package for LaTeX: the number of physics presentations I've seen using it in recent years indicates that I'm not alone in that belief. Once you're past the initial learning curve, you can do great things.

The list

And with that it's time for the big list of things to bear in mind:

Content and timing (they're connected!)
  • First things first tailor the talk length to the time you've been allocated. A good rule of thumb is to have around one slide per minute --- this will focus the talk on the important aspects and give you time to explain properly what you're talking about. Try it out and find your speed: personally I should leave more than a minute per slide if I don't want to be rushed. * Having recently given an hour long seminar which was actually 1h20 in length, I'm reminded how easy it is to ignore the above tip when you have lots of material and you're convinced that everyone will want to know it all. They won't. Be ruthless with your own material and if you realise that you're over your nominal page limit, then push the "details" slides into a "Backup Material" appendix after your "Conclusions" slide. * Don't fill your slides full of large paragraphs of text --- cut them down to minimal points and then elaborate on them when you speak. I'm very bad at this one since I want my talks to be readable by people who aren't necessarily there at the time, but I've found that writing the slides as prose first and then cutting them down to "bullet point" statements helps to focus the talk anyway. * If you have got a lot of material, don't try and force it on to a small number of slides with small text. Use more slides and large fonts instead: 20 pt or greater is a fairly sensible size (NB. If using Beamer, then the slides are produced smaller than landscape A4 so that normal fonts can be used: use the "bigger" class option to get a font that is actually 12 pt but when magnified has about the same effect as 20 pt). * Make sure you've been allocated a sensible amount of time for what you're talking about. If not, cut your talk down to size... or ask in advance for a longer slot. * If your talk is quite long (say, 40 mins or more) then think about having a frivolous 5 minute interval. I have about a 20-25 minute attention span in seminars, and an amusing distraction at 20 mins can be just what's needed to retain my attention for the second half of the talk. People will also remember it --- I'm sure my interval sessions on Cambridge night climbing have been more generally memorable and entertaining than the physics content! * If you have vivid analogies for any of the ideas you're describing, find a nice image online and use it to reinforce the metaphor on the slide. It will also brighten up the slide without having to resort to gradient-fill backgrops. * I have a personal dislike of "overview" sections in talks less than an hour long: my pet hate is the inclusion of "Summary" in the overview! Maybe this is just a personal thing, but breaking from the textbook format can be a good idea, sometimes! * Define acronyms. This is always a good idea.
  • Use a white background and sans-serif text, unless you are a design guru and can really match all the elements and colours brilliantly. It's at least as attractive as gradient backgrounds with funky "Word-art" shaded text if you design it nicely (ask Apple's advertising agent) and everyone will be able to read it easily. Also, it won't waste as much ink/toner when people download it and print it out later. * If black text on a white backdrop is too stark, try using a dark grey or blue text instead --- this helps to anti-alias the text against the background and make it more readable. Judicious use of colour highlights through the text will mean it still ends up looking pretty! * Equally, make sure that your text does stand out from the background: common errors are "red on navy" and "LaTeX-green/yellow on white". If you're using LaTeX then redefine the default green to something a bit darker before using it! The same rule applies to the green used by gnuplot as its default "second dataset" colour. * If you present photos, try to take the photo with the subject mounted on a white backdrop. That way the audience will be able to see it more clearly. It also looks more "professional" or "slick" if your photo background merges neatly with the slide background!
  • Use error bars whenever possible on plots. This is more a physics issue than a presentation one, but without error estimates the results are a bit meaningless. If you don't have error bars, make a comment about the errors in the text so that people who download the talk can still understand it. * Put titles on graphs, declare what they are (and if possible what their characteristic shape means) and label the axes carefully. * When quoting numerical figures from your slides, be sensible about the number of significant figures you read out. Aside from the technical concern of not quoting to less than the uncertainty, there's a listenability issue: your point will be made much better by quoting "6157892 events" as "just over 6 million events" or "6.2 million events" than it will if you insist on quoting down to the last digit. You can keep the data on the slide to full accuracy if you want, but your role in explaining the slide contents will benefit from a more human approach!
Storage, and the "offline" audience
  • Put all that you want to say on the slides: people will often want to reference your talk afterwards, so make sure it is a good reference for all the important points that you make. For the same reason, think twice before using animation effects...when printed out, none of the points made by the animation will still work. A good diagram is better than a flashy animation. * Put your name, the date, the meeting and the slide number on each slide: again this is useful for later reference. * If the talk is to be downloadable later, make the filename contain the details of your talk: date, meeting, subject and your name are all useful info to put in the filename. Join them together with hyphens rather than spaces, this way you won't end up with filesystem problems. * Don't rely on animation to present information: the printed and stored versions will not contain your results. This is mostly a nasty side-effect of PowerPoint presentations --- be careful that your presentation remains useful and accessible as you add more bells and whistles like this. In particular, animated overlays which sequentially layer on top of other information will only end up showing the top layer when printed. The same goes for PDF copies generated from the e.g. PowerPoint originals, for example those generated when you upload a presentation to the CERN document server. Bear in mind that this can backfire on you if the PC from which you give your talk doesn't have PowerPoint --- this is guaranteed on Linux machines.
  • Be careful with your choice of fonts: don't just use things on your machine that will not be generically available. If the computer from which you present your talk (or on to which a reader downloads your talk) doesn't have the required obscure font then your slides may be reduced to gibberish: this is often seen with Greek characters and arrows in HEP PowerPoint presentations. Arial, Helvetica and Times fonts are very professionally designed and will work pretty much anywhere. * Still on fonts, my really recommended course of action is to always give your talk from a PDF, having made the PDF with embedded fonts --- this can be set in an options menu if you're using Acrobat to do the conversion. Presentations written in TeX/LaTeX don't usually suffer from this problem since they embed the font metrics in the PDF file. As far as I know PowerPoint doesn't allow direct embedding of fonts for security reasons, though I'm not familiar with the program.

That's all for now. Did I get it all wrong? Do you have better ideas? If so, email me (see for the address and latest version of this document).