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](http://perl.plover.com/yak/presentation/). 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](http://latex-beamer.sourceforge.net) 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 www.w3.org.
### 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](/projects/nightclimbing) 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.
#### Design
* 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!
#### Data
* 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.
#### Fonts
* 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
www.insectnation.org for the address and latest version of this document).