If you're a Windows user, if you'll be making short screencasts that won't require editing, and if you need to produce them only for other Windows users, the free Windows Media Encoder is incredibly handy. Recently on a visit to Redmond I was on the receiving end of a demo given by a Microsoft product manager. A few minutes in, two things struck me. First, if he were to screen-record the demo, he'd have bottled something that could be redistributed. A one-to-one communication could also reach many. Second, if he were willing to give me the recording, I could use it to take his story to readers of my blog. The following dialogue ensued:
Him: How would I do that?
Me: Download and install Windows Media Encoder.
Him: What's that?
Me: A free Microsoft product.
Him: Where do I get it?
Me: (Googling) www.microsoft.com/windows/windowsmedia/9series/encoder/
For more ambitious efforts that require editing, capture on non-Windows platforms, or distribution to non-Windows platforms, you'll need to replace (or augment) WME. I've mostly used Camtasia Studio, but recently did an all-Mac project using Snapz Pro X for video screen capture and iMovie HD for editing.
Camtasia conveniently bundles capture, editing, and production into a single application. But its video editing capabilities are weak in comparison to iMovie HD's. I'd like to see a stronger editor in Camtasia, and/or easier, faster, and more reliable ways to transcode video so that I can mix best-of-breed capture, editing, and production tools.
No matter which tool you use, here are some basic guidelines for effective screencasting.
Although you can capture your entire screen, you probably don't want to. Even with the best compression, output files can weigh in at well over one megabyte per minute. Extraneous screen real estate is just costly overhead. And if the captured screen is larger than the playback window, things get really awkward for the viewer. Use the same rules that guide your delivery of any other kind of web content. In my case, I've concluded that 1024 by 768 is the hard limit, but if I can tell the story in 800 by 600, that's even better.
It may sometimes be necessary to maximize the window containing your subject application, but avoid that if you can. Usually, I find it's possible to size the window smaller. Beyond shrinking the output file and averting playback conflicts, this can be a great way to tighten the visual focus and thus sharpen the impact of the screencast.
Here's a principle that also applies to ordinary static screenshots: Lose all unnecessary chrome. Cropping the video capture focuses the reader on the action. If your subject application is running in a browser, viewers probably don't need to see the title bar, toolbar, status bar, or scrollbars. The address window is relevant if you'll refer to the URLs displayed in it, otherwise not. Similarly, the link bar is relevant if you're demonstrating bookmarklets, otherwise not. In general, whatever doesn't help you tell your story is just baggage. Dump it and focus on the story.
When the subject involves multiple applications, and/or multiple windows popping up within a single application, you'll want to set your capture tool for a rectangular region of the screen rather than for a specific window. Then run through the sequence, sizing everything to fit inside that rectangle.
When you've got a short story to tell, it may consist of only a single scene. You can do a lot in 90 seconds of narrated video. You might need a couple of takes, but you can probably create something that's directly usable without requiring post-production. As you attempt longer and more complex screencasts, though, it gets harder to avoid editing.
If you don't have a video editor that's compatible with your capture tool, clearly you won't be doing any editing at all. That needn't be a showstopper, though. You can tell a story in scenes by creating a series of short screencasts and presenting them on a web page.
If you do have a video editor (Camtasia Studio includes a video editor; with Snapz Pro on the Mac, you export to iMovie and edit there), it's tempting to capture an entire session in a single pass. But even in that case it's probably a good idea to capture a series of modular chunks. Just because you can carve scenes from a single large file doesn't mean you should. Working a scene at a time can help you think about each scene's role in the larger production. And depending on your tools and work style, it may be more convenient to combine a set of small clips than to subdivide a single large one.
Note that multiple takes can be challenging when the plot involves state-changing interactions. If you visit a link in the browser, for example, it's going to be a different color in the next take--unless you clear your browser's memory of visited links between takes. When I made the del.icio.us screencast, I kept having to remove items I'd added to del.icio.us, so that I could add them again. And of course some actions are irreversible, like creating a New York Times account as seen in the single sign-on screencast. There's no general solution to this problem. Try for as much continuity as time and circumstances will permit.
Composing the audio narration and synchronizing it with the video is, for me, the hardest part of the job. If you have prior experience with voice recording—I didn't—that will help. But even so, you're likely to find that syncing your voice with the action onscreen is a real challenge.
For short unedited scenes, you can do multiple takes until you get it right, or as close as possible. For longer productions, though, I've adopted a very different work style. Initially I don't even try to narrate the scenes, I just capture them as video from which I trim all the fat. Then I dictate the audio for each scene in short segments. In Camtasia Studio I save these sound clips in files, load them into the video editor, and arrange them to coincide with the onscreen action. The recently improved audio editing capabilities of iMovie HD, though, make it a friendlier environment for narration.
It's exciting to make a screencast, and you'll want to share it with the world right away. But first watch it carefully, from beginning to end, more than once. Continuity problems can creep in during the editing process. There's also a real danger of exposing confidential data—either on your own computer or, if you're recording a remote session, someone else's.
When I made the JotSpot screencast, for example, I noticed only after publishing it that Joe Kraus had inadvertently revealed his cell phone number while demonstrating JotSpot's email integration feature. I immediately published a new version that omitted that detail, but it was scary moment.