LIBR 246-04/13 Web 2.0 (Spring 2010)

I like the approach that Melissa Wong, the instructor for my Library 210 Reference & Information Services class, takes in incorporating screencasts into her lessons. Her virtual lectures on Angel consist of a page of instructional text incorporating links to databases, charts in PDF format, quizzes, and short screencasts. She knows how to choose the correct format for a given piece of information. A chart in PDF is ideal for showing a complicated static relationship among multiple pieces of information, a screencast for demonstrating how to use a software interface, and text for sequential information and binding it all together. Like the Web but on a smaller scale, Her lectures consist of small pieces, loosely joined

Text is perfect for going through information at your own speed. When I read text I'm in control: I can skim or dig down into the details. I can go try something in a database and come back to the same place in the text.

A screencast is ideal for showing interaction with software. I used to write software documentation. A short screencast of a database search is much clearer than the multiple screen shots and explanatory text you'd require otherwise. However, screencasts are often not a good match for some information.

For example, an MIT Library tutorial spends almost two minutes on a map of library locations, describing what is at each location. As the presenter describes each location, she indicates with an arrow, not its position on the map (which might be helpful), but its name below the map. The presentation is deadly dull and far less useful than a static graphic with text.

No doubt a video presentation of library locations could be made interesting, but is it really worth the effort when an interactive map with mouseover text could do a better job for less work?

Melissa Wong's approach of creating short (six to eight minutes) screencasts of only the information best suited to the format means that she spends less time planning, editing, and synchronizing her screencasts. She may even be able to do a screencast in a single take with little or no editing. Maybe she can use simpler less expensive software or at least spend less time learning advanced features. And when, inevitably, the presentation must be updated, she'll find it far easier to update her many pieces, loosely joined than to redo a much longer screencast-only presentation. That means she'll be able to accomplish things she wouldn't otherwise have time to do.

And for me, as a user, I have control. If I want to go back and review how to do a particular task, I can easily find just that task. If the entire presentation is a screencast or other vodcast, I have to search through the video for the part I need. It's possible to give me some of that control with deep linking within a video, but then that's one more task for the creator to accomplish.

Of course I recognize that longer screencasts and vodcasts have their place, but we need to recognize the proportionately greater effort required to create them and to keep them from being deadly dull.