This post originated from an RSS feed registered with Ruby Buzz
by James Britt.
Original Post: A Technique for Creating a Talk
Feed Title: James Britt: Ruby Development
Feed URL: http://feeds.feedburner.com/JamesBritt-Home
Feed Description: James Britt: Playing with better toys
So, I’m giving a talk a week from today, about Hubris. I’ve been working out the key points and concepts I want to cover, but don’t have a final version. Just some notes and sketches.
However, I’ve been sort of running the talk through my head, imagining what I’ll say. It’s a useful technique, but it’s pretty intangible. I was thinking I should just write out the whole thing, as a one or more essays or blog posts, and go from there.
But I was curious about how long the talk might end up being. I have 30 minutes, and planned on four key topics or concepts, plus there’s some intro time as well. That makes for about 7 minutes a key concept. Hmm ….
About a year ago I gave a talk at an Ignite event. The rules are, you get 20 slides that auto-advance at 15-second intervals. Pretty terse.
My talk was to be a shorter version of my JRuby/Wii hacking presentation from MountainWest RubyConf 2009. That talk was planned for 30 minutes, but I think I ended up running through it in about 20.
To see what would fit into the shorter version, I decided to just wing it. I used my G1 voice recorder to record my impromptu presentation, seeing how well I could cover the material in my alloted five minutes.
Amazingly, my first take was timed just right. Maybe having slides to work with helped.
I then took my crude one-take version and refined it to match 20 slides (some pre-existing, many new to compress content). When I had something I liked, I rehearsed it about twenty times.
For my Hubris talk I thought I would try something similar. Instead of the G1 app, I set up Screenflow screencasting software on my Mac.
I had thought that I could, while inventing my talk, scribble out my slides. That I didn’t do; I ended up just describing slides and screen actions at different points while recording.
This time around the results were plain horrible. Apparently, refining an existing talk makes for a better ad-hoc presentation than working from a collection of notes and sketches. Go figure.
But this was a good thing. It made very clear that a) I really did need to think through the overall architecture of the talk, and b) carefully whittle down the material.
One reason my improv was such a mess was that, while covering this or that topic, I realized I was out of alloted time and needed to move on to the next key area. I needed up with a lot of unclear, where-is-this-going, new-here’s-something-new babbling.
On the bright side it was nice to know that lack of content was not going to be a problem.
My next step for today is to force myself to listen again to the whole rambling mess to see just where I stumbled, and to pick out the stray thoughts that apparently made sense on the spot.
I’ll then work out a better outline, and take another shot at winging it. I’ll use Screenflow again, and as the talk gets better I can start inserting slides or notes into the screencast.
What’s appealing about this technique is that it gives me an idea of how well I know the material, and helps develop a talk that should flow more naturally than if I were to just write it all out first.
If I have trouble describing something off the top of my head then I either need to bone up on it, or drop it from the talk. If a topic comes out sounding awkward or incomplete I’m better off rephrasing it or skipping it.
The slides should play better too, since they’ll be integrated into an organic piece instead of planned in some abstract setting.
The MountainWest talks will be recorded and made freely available, so you’ll be able to see how well my scheme works.
Previous Topic
