Some screencasts are carefully produced works designed to educate, entertain, or influence an audience. But the confluence of broadband, blogging, and ubiquitously multimedia-capable computers has also opened the door to ad hoc uses of the medium. For users of software products interested in explaining those products to other users, showing and telling—that is, screen-recording and narrating—can be both easier and more effective than written descriptions accompanied by static screen shots. An ad hoc screencast can also be the best way for a user to communicate with a developer about a hard-to-reproduce bug or a user-interface wrinkle.
Here are some of the ways screencasts are used.
Tutorial: A screencast that demonstrates how to use an application or service. The screencasts on my LibraryLookup page are examples of tutorials. One of the most dramatic examples of this genre is called Cracking WEP in 10 minutes. To a thumping electronic beat, it shows you how to use kismet to locate a victim, aireplay to generate the requisite hundreds of thousands of WEP initialization vectors, aerodump to save the traffic to a file, and aircrack to analyze the file and recover the WEP key. It's a stunning contribution to the literature of wireless security.
Short how-to: Examples include this 90-second short on Linky, a Mozilla/Firefox extension, and another shortie on Windows' hidden desktop search feature. For screencasts as brief as these, editing is optional because you can get a usable result in a single take. That means that almost anybody can create one, blog it, and thus make it discoverable by search, tagging, and word-of-mouth referral.
Conversational demo: My first effort here was a demo of JotSpot, the "application Wiki," in which Joe Kraus drives the demo and I ask questions. A more recent example is this co-narrated demonstration of Zend Platform. As software grows ever more complex and dependent on elaborate substrates—especially in the enterprise category—I expect that this genre will be increasingly useful as a way for developers, reviewers, and users to reach a shared understanding of the software.
Feature story: My first foray into this genre was Aunt Tillie's OS X Adventure, in which I respond to a pair of Eric Raymond essays [1, 2] on the horror of Linux's printer support. Eric had suggested that Mac programmers wouldn't make the same mistakes. But what I found on OS X, and documented in the screencast, was an almost equally bad experience.
Good old-fashioned software review: If you're reviewing a software product, for example the latest version of Photoshop, why wouldn't you do it as a screencast? That's just what David Pogue did.
Spontaneous user-produced demo: My favorite example of this genre is Paul Everitt's ad hoc demo of the oXygen XML editor, about which Paul later wrote:
I put very little consideration into making that narrated demo. I had posted something about XSLT and said it was easier than advertised. In a weblog comment, someone asked for evidence to back up my assertion. I offered to make a recording, he took me up on the offer, and I spent 15 minutes with no post-production to respond to him. [Zope Dispatches]
Capturing a screencast needn't be much more complicated that capturing static screenshots. Whether you're showing a friend how to use an application, or showing a developer what's wrong with one, the ability to make and share screencasts easily and naturally promises to revolutionize the flow of information supporting the use and development of software.
Animated whiteboard: Troy Stein, product manager for Camtasia Studio, made this screencast for the soccer team he coaches. It's particularly well suited to the Tablet PC, but you could use sketching software on any platform to achieve a similar effect.
Screencast-enhanced video: Although most of my screencasts have focused mainly on software action, with bits of live video sometimes spliced in, my screencasts about a flood and a pumpkin festival reverse the emphasis. They're mostly video, with bits of screen animation interspersed to contextualize the scenes. You can see the same mix of ingredients in this David Pogue video. His review of a hard-disk-based camcorder is mainly video, with just one short screencast to illustrate the use of the camera's software.
Concept screencast: The ACLU's digital identity nightmare is a screencast about software that doesn't exist, but could: an application for a pizza store order-taker that violates the customer's privacy in a dozen different ways. It's a powerful polemic that's influenced a lot of people. I've argued that architects of more humane digital identity futures ought to be using the same medium to communicate their alternative visions. In general, concept screencasts can be a great way to explore alternative software-based realities.
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.
Wikipedia's screencasting page mentions a number of tools, and points to this useful roundup.
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.
The specifics will vary depending on the tools you're using, but here are some general principles to keep in mind. I've found editing screencasts to be a two-way negotiation between the video and audio tracks. In some cases I'll extend a frame of video to cover a crucial bit of narration. In other cases I'll rerecord a snippet of audio so that it covers some crucial action onscreen.
Of course this approach presumes that you're the sole narrator. That's not always true. Some of the screencasts I've done are conversations recorded over remote screensharing sessions. Those situations present fewer editing options. I usually record the audio and video tracks together, with the screen capture tool's built-in audio recorder, and then edit them as a single track. It's quick and easy to excise unwanted segments.
But if you need complete control, record the video track using a screen recorder, record the audio track separately, and then combine segments as needed. I'm working on a project now that requires this treatment; it's challenging but doable.
Here's something that's unique to screencast editing. Capture tools record every little detail of software interaction. A lot of this micro-behavior—wandering around with the mouse pointer, noodling with menus, moving and resizing windows—is (or should be) of great interest to interaction designers. It's quite instructive to see how you're constantly engaged in learning and self-correction, even while driving an application you think you know well. But unless the point of your story is to reveal these low-level and largely unconscious activities, nobody needs or wants to see them. If you ditch the false starts and random hovering, you'll accelerate and intensify your scene.
With this kind of tightening, you can squeeze an eight-minute screencast down to five minutes. That's the difference between one that people will think is too long, and one they'll judge to be just right. Note that this isn't simply a question of whether viewers can spare the extra three minutes. If the five-minute version preserves all of the essential action, it will be far more impactful than the equivalent eight-minute version.
Most screencasting tools target the Flash runtime. Historically they've supported the
.SWF format; more recently they've also begun to support the newer
.FLV format. The idea is that, by leveraging the near-ubiquity of the Flash runtime, you can avoid the hassle of detecting and adapting to the Windows Media, Quicktime, and Real media players. Although
.SWF isn't ideal for conventional video—quality isn't great and quantity is limited to 16K frames—it can work well for screen-oriented content. That's true because screen video can usefully be delivered at a low frame rate (e.g., 5 frames/sec or even fewer), and because it tends to be highly compressible.
Camtasia's codec delivers great compression of screen video but doesn't do nearly so well with motion video. When you're working with a mixture of these elements, one approach is to use an alternate compressor such as Blue Pacific's Turbine Video Encoder for Flash.
If screencasting elements are few and motion video dominates, though,
.SWF becomes less attractive. You can still target the Flash runtime using
.FLV (a technique I've had little experience with so far) or you can of course target the usual suspects: QuickTime, Windows Media, and Real.
Formats and players aside, a 50-50 mix of screencasting and motion video presents a real challenge. Screencasting elements want to maximize screen real estate, and motion video elements want to minimize it. There's no easy way out of this dilemma, although Ze Frank's marvelous Communication #1 demonstrates one effective solution: two frames side-by-side, one small for motion video and the other large for screen video.
The blogging revolution has shown that, while there are few professional writers, there are lots of people who can productively use the textual web to communicate their personal and professional agendas. Podcasting is likewise reshaping the audio web, and videoblogging will do the same for the video web. When the subjects of our videos are experiences that intersect with cyberspace, or occur primarily within it, we'll use screencasts to describe and explain them.
Return to digitalmedia.oreilly.com