More and more people are adopting the frequent five-minute screencast format, which as I’ve said before is a trend I am very happy to see. Sometimes nascent screencasters get in touch and ask me for pointers. Here are some notes on what I think makes for a great short technical screencast.
First though, understand that this is based on the kinds of screencasts I make, which in turn is based entirely on the kind of screencasts I want to watch. I have no idea if my preferences are in the majority. All I can tell you is that a lot of people seem to like the RubyTapas format. YMMV.
Also, if you’re just getting started making your first screencast, don’t read this. Go watch this video from Envy Labs instead. Come back when you have a bunch of screencasts under your belt and you want to hone your skills. This article assumes that you have gotten to the point where you are editing your videos in a non-linear editor, rather than just capturing them and posting them.
According to Hollywood legend, the only direction George Lucas gave actors on the set of Star Wars was: “Faster! More intense!” over and over. That’s basically my approach to screencasting in a nutshell.
My biggest gripe with many technical screencasts is that they are too slow. The thing about videos is that unlike reading a blog post, I have to adopt the screencaster’s pace. It’s harder to skim, and even if my video player has a speed-up feature, I see it as more of a last resort.
So with my videos I try to err on the side of going to fast rather than going too slow. I make the assumption that the viewer can always pause and rewind as needed – something I often do during the more interesting parts of screencasts. When I was starting out I was a lot more timid about speeding things up, and you can see that in some of my earlier RubyTapas videos. As I made more of them I became steadily more aggressive with my pacing.
Don’t be afraid to disengage the voice-over (VO) from the video track and accelerate the video. Most programmers can follow code being written a lot faster than they can write it. My video editor has a default maximum acceleration factor of 12x, and it’s not uncommon for me to go all the way up to that cap.
Speaking of VO… there are two main schools of thought on this. There’s what I think of as the Gary Bernhardt school, where you practice over and over until you can talk while you type at a reasonably fast pace, without a lot of “ums” and “uhs” and coding mistakes. If you can make this work without a year of typing practice, go for it.
I’m a horrible typist, I hate repeating work, and I can’t think and type to save my life, so I use a very different technique. I write out my scripts beforehand, and I record the VO as a completely separate process. I don’t even look at the screen recording when I’m recording VO. This lets me focus on getting my vocal intonation and pacing right. When it’s done, the VO track becomes the timing backbone of the episode, and I edit the screen recording to match it.
I find that doing VO separately and with a script is particularly effective at eliminating the bored-sounded “programming voice” that a lot of screencasters naturally fall into. Think of your screencast viewer as a member of a conference audience, watching you present a talk. They are fidgeting because they aren’t writing code right now. You need to hold their attention, and a bored monotone is not going to accomplish that.
Finally, writing out my script beforehand gives me a chance to cut it down to just the essentials. I find that when I’m ad-libbing narration I have a tendency to go on and on about unimportant aspects of the code. Occasionally I also realize, as I’m writing a script, that I’ve used a term out of habit which my audience is unlikely to be familiar with. Scripting gives me a chance to catch oversights like this and insert a brief definition.
While you should cut extraneous content, sometimes you’ll also need to fill in empty spaces. Nobody likes dead air. As a viewer, after thirty seconds of silent tap-tap-tap-typing my attention wanders. The great thing about video is that it conveys information to two different senses at once, and it is at its best when the audio and video reinforce each other. So if you have a lot of code to write, narrate it as you write it. Speak your code. But do it without slowing the coding down. Again, you don’t have to do this “live”. For me, this means recording my play-by-play of the code separately and then “squishing” the video down to whatever amount of acceleration makes it match my voice-over.
The flip side of this is that if you have a lot to say that doesn’t involve writing code, find a way to make the visuals reinforce what you are saying. This can be as simple as video of you typing out bullet points that match what you’re saying. Or it can be a visualization, a funny picture, or even an animation. Again, think of it as a conference presentation. What slides would you show to underline your point?
Speaking of presentations… the biggest mistake most first-time presenters make is also the biggest mistake most screencasters make: burying the lede. “Today I’m going to show you the Frob tool. The Frob tool is a blah blah blah… now let’s install the Frob tool. First, you’ll need to blah blah blah…”
Cut all that. Start out with a problem. Tell a story. It doesn’t have to be long. “This one time I wrote code that looked like this, and it sucked”. That’s a story. Now show me how to fix it with the Frob tool. If you really feel compelled to give me background on the tool and show how to install it, save it for the end. Personally, I feel like that kind of information is usually best left for the show notes.
Sound quality: Get a decent USB mic. Try and insulate it from your keyboard noise. Find a quiet room. Get a pop filter. Listen to your audio on a decent pair of headphones, and then adjust. Too quiet? Move your mic or your mouth. Getting a lot of breath noise? Same advice. If you have the scratch for it get a mic with a built-in monitor so you can plug your headphones right into the mic and hear exactly how you sound as you speak. If not, not worries – just listen to yourself after the fact and adjust accordingly. I recorded podcasts for years without a live monitor.
Be aware, though that modern technology can go a long way towards fixing bad audio. Even the free Audacity editor has a noise-suppression filter that can sample ambient noise and then remove it from the recording while leaving your voice (mostly) intact. I use a similar filter to avoid the need to isolate my mic from my computer’s fan noise.
Figure out audio compression (this has nothing to do with file sizes) and normalization, and when you do, explain them to me. Meanwhile, use tools that make it a no-brainer, like levelator. These days I use a combination of Sony Wave Hammer and iZotope Nectar Elements, which have some excellent presets out of the box. Or, get your mic technique Good Enough and then ignore this whole paragraph because unless you’re doing screencasts for audiophiles you’re not going to get a lot of complaints that “the content was good but the audio compression sucked”.
Edit, edit, edit. Then edit some more. Edit pauses, edit “ums”. Edit parts where you explain something tangential to the main point of the video. Edit mercilessly.
You may use a low-contrast editor theme for daily editing, but consider switching to a high-contrast theme and upping your font size for screencasts. Remember, people are going to be watching this in a window or maybe even on their phones. Make it pop.
Most importantly, remember why you are doing this. Technical screencasts are like the broadcast equivalent of pulling your coworker over to your desk and saying HOLY SHIT CHECK THIS OUT!! Remember that it’s all about the joy of sharing. Love your subject matter, love your audience, and let that enthusiasm bleed through the screen.