Speaking at NSConference

On Monday 4 March 2013 I will be presenting a short talk entitled ‘Searching for Speedy Searching’. Although I volunteered to talk it is a scary prospect, particularly since I’m not a natural public speaker or presenter. I’m definitely on a learning curve for this stuff and no expert but I thought I’d note down a few ideas and thoughts I have about it which may either help other people in a similar situation or, even better, prompt some more polished speakers to offer me some tips.

  1. Try not to ‘erm’ all the time. I am fortunate that I’ve been allowed to take part in the iDeveloperLive podcast a few times over the past couple of years. Whilst I hate listening to myself on the show I do force myself to, simply so that I can try improve my speaking style. One thing I noticed very quickly in my earlier appearances was how much I was saying ‘erm’. Now I try to simply pause whilst I gather my thoughts and consider what I’m going to say next. Brief pauses also help the audience take in what you are saying.

  2. Try to maintain eye contact with the audience even though you can’t see most of them. When you speak at a conference the chances are that there will be bright lights shining on you. This means that your view of the audience is limited which is a good and bad thing. It’s good because it helps with the nerves. You can only see a few people right at the front. It’s bad because it makes maintaining eye contact with your audience harder. You might not be able to see to the back of the room but you still need to look there. Look around the room and, even if it’s not really happening, pretend you are maintaining eye contact with your audience.

  3. Keep slides simple. There are books and websites devoted to creating effective presentation slides written by far more knowledgable people then me so I’ll just summarise a few tips and ideas I have.

    • Last year I created white slides with black text. This year I’m using Keynote’s Gradient theme with large white text. This is what the majority of the speakers used last year and white text on a dark background does seem to work a little better under bright lights.
    • Last year I used lots of images and animations in my slides. This year I’m using very few images (and may reduce it to none) and minimal animations. The animations are restricted to things like highlighting areas of code and are very quick and simple. You want people to concentrate of you and what you are saying and not watching your slides.
    • My slides contain the minimum amount of text possible. In several cases they contain just a single word. They are not meant to be the text of your talk or distract from what you are saying. Having said that, I do have one slide where I present a quote verbatim and I do have several slides which contain multiple lines of code.
    • The other advantage of using few words per slide is that you can make the text really big. Bigger text is better and it means that people at the back of the room can still see what you have written on them.
    • Presenter notes are your friend. Use them to not only remind yourself about what you need to say but also to remind yourself that you need to click to start an animation of some sort on the slide. For example, if your slide contains a movie then add something like ‘[CLICK]’ to your notes to remind yourself about when you want to start the movie.
    • Presenter notes are also useful timing helpers. When you are working through your talk you will see a clock of the elapsed time since you started. Every few slides, the equivalent of every few minutes anyway, add a time target to your notes. This will help you change the pace of your talk if necessary so that you can hit the expected duration of your talk.
  4. Have someone else proof-read your slides. I’ve added this one as a post-conference tip, and one I learnt the painful way. WWCD is not the abbreviated name for Apple’s Worldwide Developer Conference.

  5. Practise. And record your practices. I use ScreenFlow to record myself presenting my slides out loud. This has a few advantages:

    • You can see how long your presentation takes and then work out where you need to adjust your content to make it shorter or longer.
    • You can hear yourself presenting. You’ll notice and become aware of those ‘erm’s. You’ll hear where you stumble over words or phrases so you can then re-think what you are going to say. You’ll get your pacing right. Saying things out loud is very different to saying them in your head.
    • You can watch the presentation back and see if slides make sense, if animations work, etc. You become the audience rather than the speaker.
  6. Relax. Yes, standing up in front of a room full of your peers can be scary but you have information and knowledge to impart so relax and enjoy it. If the conference organiser has okayed your talk then you know it is something people will want to hear about. Because it is something you chose to talk about you should be interested and enthusiastic about it which makes talking about it much easier. Walk about, wave your arms about, pause, breath, relax.

  7. Ignore this advice. If you’re also speaking at NSConference in just over a week and your slides are nothing like I’ve suggested then don’t rush off to change them. As I said at the start, I’m not an expert and I’m always looking to learn from others. Prove me wrong and do a great presentation regardless of my suggestions.

Matthijs Hollemans also pointed me towards this video about Mike Lee talking about presenting.

Two additional points from William Scarvie:

  1. Strive to deliver key points in memorable moments. If possible use humour to help here. [But if you’re not comfortable trying to be funny then it’s best to avoid it entirely - SW].

  2. If your talk includes content the audience will want later such as code then refer to a detailed blog post where they can get it from.

Drew McCormack also suggests telling stories if possible. Don’t just give the solution to a problem. Tell the audience how you found out. Tell them if another approach was tried first which failed and then explain how you arrived at the solution that works.