I am an immediate fan of Common Craft’s style of concept videos. Their explanations of how and why to use del.icio.us and Google Docs are crisp and entertaining. They convey the essence of these activities more clearly than any other visual explanations I’ve seen, including many of the screencasts I’ve made.
The style is called paperworks because these sketchcasts are made by capturing screenshots, printing out key elements, and then filming, animating, annotating, and narrating arrangements and rearrangements of these scraps of paper. The first time you watch one, you’ll be captivated: it’s cute, it’s fresh. But is this just a gimmick? After you watch a few more, and you begin to acclimate to the style, does its effectiveness wane? Not yet, for me, because these productions have more going for them than cuteness and freshness.
One of the principles at work here is the moral equivalent of cropping and zooming in the screencast medium. When you’re trying to explain software on a conceptual level, images captured from screens can be a mixed blessing. It’s valuable to show exactly what screens look like, and exactly how actions flow within and across them. But the amount of detail that’s visible in a typical screen can often distract from the story you’re trying to tell. By cropping the screen, and/or by zooming in on the active region, you can prune away a lot of visual clutter and focus on key interactions. The paperworks style is an extreme form of cropping and zooming; it prunes and focuses very aggressively.
Another principle is sketching. According to Bill Buxton, sketching goes hand in hand with what he calls design thinking. When I asked Bill how he would have used sketching in the design of a feature like the Office ribbon, he said:
You’d start with paper prototyping — quickly hand-rendered versions, and for the pulldown menus and other objects you’d have Post-It notes. So when somebody comes with a pencil and pretends it’s their stylus and they click on something, you’ve anticipated the things they’ll do, and you stick down a Post-It note.
If that’s a helpful way to imagine software interaction in the design phase, why wouldn’t it also be a helpful way to conceptualize the software in use? The paperworks style strongly suggests that it is. These sketchcasts are great visual explanations of working software. I suspect they’d be equally useful during the design of that software.
Thanks so much for the kind and insightful words John. One of the things we’ve learned through the process is that screens introduce noise that interferes with with the message. If we need to show a screen shot, sometimes we’ll print out the screen and chop it up so we can remove the noise – and focus the viewer on only the elements that matter. Now that you mention it, it does a bit like a paper prototype.
I love them as well. I’ve been looking for good technique for doing screencasts this week. I’m starting to realize that it’s a lot easier to convey how software works and what value it adds for the user.
I tried to get my dad to use del.icio.us by watching a screencast I had made. Somehow he did not warm up to the concept. I then sent him Lee Lefevers paper-sketchcast after you talked about it. He was bookmarking in no time.
The moving paper does make it easier to focus your attention to the key concepts . Even zoomed representations of the same gui elements during a screencast dont achieve the same purpose. Maybe this something to do with the way we are wired.
Let me add my kudos. I introduced delicious into my graduate education course as an assignment and the students just were not getting it. I then embedded Lefever’s video into my Blackboard explanation of delicious, and the students were off and running. The assignment only involved exploration of delicious, but ten weeks later, I checked and 22 of 24 were actively tagging. Lefever’s video helped an entire class “get it.”