Yesterday[base ']s screencast turned out to be a nice example of how the screencasting medium can communicate what otherwise cannot be explained easily, if at all. Here[base ']s the kind of reaction you hope a screencast will elicit:
I checked out the Photo Gallery earlier, but didn[base ']t see the added value. Now I do.
It[base ']s hard to quantify the impact of a timely and well-produced screencast, but my gut tells me that Simon Willison[base ']s outstanding effort, How to use OpenID, has more than a little to do with the momentum now building around OpenID.
I[base ']ve written before about how to make screencasts that communicate effectively, and I[base ']ll be updating those observations from time to time because it[base ']s an evolving story.
One of my goals is to help folks inside Microsoft use this medium more effectively. Another is to help everyone else do so, because there[base ']s a major obstacle in the way of my vision of the future of software and networks: Much of the value and capability of this stuff is unappreciated by most people.
In trying to understand why, I[base ']ve settled on what I call the [base "]monkey with a termite stick[per thou] argument. If you[base ']ve heard it before, skip ahead. If not, it goes like this. People learn to use tools by watching how other people use them, and imitating what they see. Observation is the key. Suppose monkeys had language, and the discoverer of the termite stick could explain to the tribe:
[base "]So, you find a stick about yea long, and strip off the bark so it[base ']s sticky, and poke it into the hole, and presto, it comes up bristling with yummy ants.[per thou]
Some of the other monkeys might get it, but most of them wouldn[base ']t. On the other hand, any monkey who could observe this technique would get it immediately, and never forget it.
Given all the network connectivity that we have nowadays, it[base ']s perhaps surprising [~] but nevertheless true [~] that we have few opportunities to directly observe how other people, who are proficient users of software tools, do what they do. Screencasts are the best way I[base ']ve found to make such tool use observable, and thus learnable.
Enough theory. When you get down to brass tacks and try to capture those [base "]aha[per thou] moments, it[base ']s easier said than done for a bunch of reasons. In the case of this particular screencast, I just want to point out three things.
Focus.
I always ask presenters to size the application window (or windows) to something like 800 by 600. That[base ']s partly to minimize the quantity of video that has to be delivered, which continues to matter because broadband isn[base ']t yet where it needs to be. But equally, it[base ']s a way to focus on the real action. In the case of the Photo Gallery screencast, for example, I cropped away the window chrome because nothing was going on there. It[base ']s a subtle and subliminal thing but, when you eliminate the uninteresting and uninformative, the interesting and informative aspects of what remains will emerge more clearly.
With some screencasting tools, including the one I mostly use, Camtasia, it[base ']s also possible to also pan and zoom in order to focus even more precisely. I haven[base ']t used that feature, yet, because I[base ']m usually pressed for time and the basic kinds of editing that I do are already time-consuming. But I do want to add this technique to my repertoire, and use it in selective and appropriate ways.
Editing is crucial. The raw capture for yesterday[base ']s screencast was 30 minutes. It included some false starts, some extraneous material, and a fair bit of verbal stuttering on the part of both Scott and myself. When we finished the capture, I wasn[base ']t sure we even had anything that would be usable. But as I trimmed away the clutter, a reasonably clear storyline emerged.
Even the 14-minute version will, of course, be too long for many people. One solution would be to divide the material into chapters. But since none of those would work well standalone, a better solution might be to make an elevator-pitch version that tells the same story in just 3 to 5 minutes. I[base ']d want that version to complement the 14-minute version, though, not replace it.
Interactivity.
Almost all the screencasts that I[base ']ve seen, and many that I[base ']ve made, are solo efforts. But I also love to do interview-style screencasts, and the Photo Gallery screencast is an example of that genre. When it works well, as I think it did in this case, the interaction between the interviewer and the presenter can help the presenter [~] who in some ways knows the subject too well [~] recognize what[base ']s not obvious to viewers and adapt accordingly.
As an aside, I should mention that although we made this screencast remotely [~] Scott was in Redmond and I was in my home office in New Hampshire [~] we used a technique that was new for me. Normally I record screens projected to my computer using a screensharing application. In this case, because of all the images in the presentation, that didn[base ']t work well. The projection couldn[base ']t keep up. So I had Scott record his screen on his end, while I recorded the audio on my end. It worked great. I was able to follow the visual action well enough on my end, Scott captured a high-quality video which he later posted for me to download, and it was straightforward for me to marry up his video track with my audio track.
Show, don[base ']t tell.
The [base "]aha[per thou] moment, if there is one, speaks for itself. When the monkey can see that termite stick bristling with ants, there is no need for someone to say: [base "]This is a really cool benefit.[per thou] It[base ']s just obvious.
In our session, Scott was actually quite restrained. But there were a few places where he made editorial comments like [base "]this is really convenient[per thou] or [base "]this is a great benefit[per thou]. I took them out. If I could give only one piece of advice to technical marketers everywhere, it would be this: Show me, don[base ']t tell me.
