December 2009 Archives

Notes on Talking with Slides

I gave an internal company talk reporting on my trip to OOPSLA this year. Here are some notes on the experience.

Things I Would Do Again

Focus on some small, interesting topics

The conference lasted for five days (including the Sunday before the "official" start). I attended mostly tutorials but also a limited number of conference talks. Instead of trying to summarize everything I saw, I picked five topics that interested me. In the end I only presented four.

Avoid Wasting Time With Slideware

This time I created my slides using something called S5, so it was all one big HTML file. This meant I was editing using a tool I know well (my favourite text editor, vim). S5 has its quirks -- notably, it seems to behave differently in different browsers -- but the file format is relatively transparent and easy to modify.

Allow Plenty of Time for Preparation

I decided in advance that I was not going to rehash the material I had already seen. I had a CD with the slides of the presentations I had seen. Instead of copying those I researched the background and came up with my own take on the ideas. This meant many evenings and weekends googling for and reading references.

Break Up the Talk

I gave four mini talks, not directly related to one another. They varied in length and style. There was a good chance that most people found at least one part interesting.

Involve the Audience

I did steal two questions from a "Jeopardy"-style quiz that the OOPLSA organizers staged one evening. I started out the talk with these two questions. If nothing else, it gave me a chance to ensure that at least a few people were awake.

Put the Question on a Slide But Not the Answer

One effective way to motivate the audience is to tweak their curiosity. Putting the answers on the slides makes them complacent. If the answer isn't on a slide they have to listen to get the answer.

Move Material From Slides to Notes

There is a strong temptation to make the slides an outline of the entire talk. This has a powerful soporific effect on the audience. The slides should be a small part of the talk, only drawing attention from time to time.

Changes I Would Make If I Did It Again

Cut Ruthlessly

This means fewer slides and less material on each slide. I figured initially that a minute a slide ought to be about right on average. I didn't run out of time but I did rush the last part of the talk with one eye on the clock.

Avoid Abstraction and Generalities

People tend to understand specific, concrete examples better than more general, abstract statements. This seems to be even truer when they are listening to a talk. Even worse, the general and abstract seems to send people to sleep (not literally but their attention drifts).

Plan More Occasions to Engage the Audience

This would give me a chance to wake them up if necessary. It would also be a chance for me to see how much they are getting it.

Make Sure I Understand Everything I Plan to Say

Towards the end of my talk I came across a slide that included a point that didn't make sense to me when I read it in front of my audience. I stumbled and it was noticed and I'm sure it cost me some credibility. The emphasis is on everything. This means reviewing everything, especially the stuff that's written last thing at night. During the review, I want to make sure I agree with and can support with everything I plan to say.

Break Up Monotony in the Slides

I had very few images in my slides, mostly because I found the amount of work to create my own images burdensome and I found it hard to think of existing images that I could use that would be relevant. In future I'll look into something like Inkscape.

Ruby Notes

Mongo

In order to install the mongo_ext gem, I had to first ruby1.8-dev package.

Explicit Breakpoints

Nice to examine a failing rspec test: just insert require "rubygems"; require "ruby-debug"; debugger at the relevant point in the code. (From an rspec mailing list)