This is part 3 of the "The art of speaking à la Tim" series:

Your talk has been accepted? Congratulations! Now is time to get on with creating it.

3. Prepare the talk

3.1. Presentation Style

In the very first part, you must have thought about the form and a style/tone for your presentation. This is where those two come back into play.

Public speaking is first and foremost your personal performance, but you can incorporate the audience in your talk with various degrees:

  • Frontal-presentation: this is very much the university presentation you would expect, you are speaking and everybody else isn't... or at least shouldn't
  • Participative: you encourage questions and incorporate them in your flow
  • Interactive: you explicitly require participation. I've seen it done with live voting, real discussion between two or more attendees and also writing down sticky notes for the speaker to use...

Depending on the topic you are addressing, what you want to transmit and how you want people to react to it, you might want to chose one or the other. For instance, bashing a topic - that some people in the room might feel deeply linked to - using an "interactive" style will end-up in battle of opinions that will throw any presentation plan out the window. Still, that sounds like a fun talk to attend to :D

Talking about code, there are different ways to incorporate it in your presentation:

  • Code in slides: your slides contain some code. This is the easiest way to get technical with a safety net.
  • Demos: you will switch into an IDE at some point
  • Live coding (no slides will be harmed): you have two slides to say "hi" and "bye", the rest is done in your IDE. This is the one that scared me the most before, but the adrenaline rush is like none other!

All those are OK, and have their advantages and drawbacks.

  • Code in slides is the least engaging for your audience, but it allows to cover more complex concepts faster. My rule of thumb there is: "do people need to see X configured / starting / running? Or is it enough if they get an idea how it will look like?"
  • Demos is ideal to... demo a concept explained in the slides. Ideally, you should have presented the basic concepts in the slides and are about to demo them by building something bigger that aggregates a few of those together. The demo should really add value to the talk by showing that it is possible to handle the complexity of the concepts on stage in a very limited time (1).
  • Live Coding is ideal to show the whole lifecycle of the solution you are presenting and thus prove that it is indeed the easiest/best/most powerful way to do things. In a way it's like going naked on stage to show that what you are in the "no-bullshit" zone: the code is so clear (1), I don't need slides and neither do you (2).

(1) Be very cautious with the flow of your coding. If you are demoing something, it is to get everybody's attention on what you are doing, and incrementally understand where you are taking them. Do not drag-and-drop or copy-paste snippet of code, there's no better way to lose your audience or give them the impression that what you are doing is not as easy as you said. The only good reason to do it is when you reached a wall. You typed it live and must have made a mistake that you cannot find (due to the stress probably), then you should have some snippets ready to help you get back on tracks.

(2) Be very cautious with this. It might be that you don't need slides, but your audience might (do you have a visual memory?). Summarizing concepts with one big picture or putting things visually in relation helps a lot of persons. I also love the live coding idea, but don't let your hubris or rocking the stage with VIM take the best of you.

So pick the right tool for the job!

3.2. Getting your hands dirty

The first rule about making slides is not to make slides. Like many things, early optimization can be deadly. This is why I replaced Powerpoint & Keynote with a markdown based approach with Reveal.js. I encourage you to work in a text editor until you are happy with the content.

So let's get down to it. In the first part you described many things that we want to build upon:

  • "What I would like the audience to get out of the talk". Whatever you do, always come back to this goal. If you build something in a slide that doesn't serve this goal, consider removing it or putting it into your backup slides.
  • "3 to 5 ideas that must fit in"... make sure those are in.
  • "What is the minimum I expect from the audience and what is the most complex idea I want to transmit". When I build a talk, I like to present the most complex idea about 1/2 or 2/3 into the presentation. The beginning of the talk is there to enable you talking about this. The rest of the talk is there to summarize/consolidate all the concepts you presented and then add a "going-further-gem" to give the "best listeners" something to chew on.

Then start writing a bullet point wall of information. It starts with those 3 to 5 ideas. Add the prerequisites and the most complex ideas you want to thrown in. Add some sub-information and precise your thoughts incrementally. You should end up with a long list to things to talk about.

At that point, start splitting your ideas into paragraphs that will end up being slides. Treat each paragraph like a small presentation in itself:

  • What should the audience get out of it?
  • What are the 1-3 ideas you want to convey?
  • Try to write some "speaker notes" to explain why this slide is needed, and then consider adding those information in the slide itself.

Don't hesitate writing a lot. Those words will be useful as presenter notes afterward. I tend to write a lot of those, capturing all the things I want to express around the slide. Then I experiment with the content of the slide to get to the best way to express this idea. I might end up splitting the slide or combining two back together.

3.3. Some tips

  • People tend to remember the beginning and the end of the presentation pretty well, the rest... a lot less. Make sure they don't remember what you did 5 years ago and the credits to other people's work. Put some important information there. In my DevJourney talk for instance, I start with some emotional-check with the audience to make them feel the problem of craftsmanship and learning with their own past. In the end, I wrap up on some information about the project itself. That way, if they indeed only remember the beginning and the end, they will have understood the problem I want to tackle and they know where to look for my information.
  • Beware to walls of text. People usually read or listen, but not both. Make concepts fast to read on the slides (bullet point) and use those to give an idea of the structure of your talk. The meat of your slide will come from the added value of your voice (unless your presentation is supposed to be 100% understood in its written form).
  • Pay critical attention to the flow and the logical transitions. The transition sentences is typically something I write in the speaker notes and I try to help myself by putting something on the slide that will help remember and trigger that transition.
  • Pay attention to the tempo of your presentation. One may be tempted to go boom-boom-boom adding concept after concept. That might be too much. Plan some ups and downs, some time for the audience to gather their thoughts. Summarize and recapitulate often and don't forget some time to breath with some jokes to help you and your audience relax. Remember that if you are a master in what you are presenting, it can be very taxing for your audience to follow you. Help them!
  • I try to only write an idea onto a slide if it adds value to see it written there. One question to ask yourself: Would someone take a picture of this slide and tweet it? If not, ask yourself why and modify the slide accordingly. Too little information for the slide to express an idea in itself (a bit like a keynote slide with a picture and a word) or too much information that wouldn't be readable on a picture?
  • Whenever possible, make extensive use of images (but pay attention to copyrights - I tend to make all the images myself nowadays).

A final note on your cover slide. When entering the room, your presentation will most likely already be up on the projector, and may remain there for a while before you are allowed to talk. What are the people seeing? Is it setting the tone for the talk? Do people wish to see more when they walk by the room and see it through the open door? Is it making them want to tweet it and attract more people?

How do you react when you peek into a room and see the speaker with plush-unicorn in his arms? I'm setting the tone...

Finally, remember this Antoine de Saint Exupery quote and start trimming down your slides again and again:

"It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away."

Congratulation, you now have version 0.x of your slide-deck ready. You've made great progress, but the refining road is long ahead of you.