Random and cold medicine-induced thoughts on screencasting

Last summer, I was talking with someone from the planning committee of the Dartmouth Biomedical Libraries’ Fall Conference. Their theme was “Cool Tools and New Technologies” and I asked her if they were going to have someone speak about screencasting. Her response was “but everyone knows about screencasting already.”

Really?

Maybe I travel in the wrong circles, but I know plenty of librarians who know little or nothing about screencasting. And even if they know about screencasting software, many of them have never used it themselves.

According to Jon Udell, the man who coined the term screencast (though the software has existed since the late 90s), “a screencast is a digital movie in which the setting is partly or wholly a computer screen, and in which audio narration describes the on-screen action.” Screencasts are often used to demonstrate software and so are great for library tutorials. What’s so cool about it is the fact that instead of reading a list of instructions on how to use a database or some other tool, a screencast concretely shows the librarian going into the database and executing searches. I’m the sort of person who needs to see something done to learn how to do it and I’ve never been able to learn much from text instructions. Screencasts are all about video, but often also include audio, captions and even interactive components. You can show a user how to do a search and then have them execute a similar search before the screencast will advance.

Lots of academic libraries have created tutorials on how to use library databases, the catalog, ILL, etc. However, I haven’t found too many public libraries using screencasting, though the two examples I have found are great ones. I am in love with the Calgary Public Library’s basic Internet tutorials — they’re concrete, interactive and really polished. I can’t imagine how long it took to produce these. The tutorials at the Orange County Public Library are pretty spiffy too.

When I first discovered screencasting three years ago (before I even worked in a library and before screencasts were called screencasts) I thought it was the best thing since sliced bread. I was blown away by how easy it was to create a Flash movie of your desktop with very little in the way of tech-savvy. You can make a very basic screencast — that you film and narrate simultaneously — in 20 minutes. Or you can spend an entire day or more developing a really polished screencast tutorial. Other than the time invested, screencasts are pretty easy to create. I tried out Camtasia and Captivate (and reviewed them here) and found them both really intuitive. I’m still very excited about screencasting, but my enthusiasm has been tempered by the realities of creating them for library patrons. I thought I’d be creating screencasts day-in and day-out when I first got my job, but I have realized that it’s not always the best solution.

Screencasting has some major drawbacks. The first is the size of the file created. A movie of just five minutes can be as big as five megabytes, which is fine for those of us with broadband, but for people on dial-up, it can take forever to download. I recently created a screencast introduction to library services and resources for our online learners, and I felt that I had to create a text and screenshot HTML version of the same tutorial for students on dialup or those who can’t play audio for some reason. In addition, they take up lots of space on the server and can be real bandwidth suckers if they get a lot of use. Another issue is that databases and other things we might be demonstrating may change, forcing us to completely redo our screencast. I’d created a screencast on using Thomas about a week before they redesigned their Website and had to do it all over again. I’ve also completely redone our Web portal for distance learners since creating this screencast for Academic Search Premiere (though the students still could probably figure out how to find the database). Finally, screencasts can take a long time to create. I’m sure there are some people out there who can competently narrate a screencast and do the screen capture part flawlessly at the same time, but I’m definitely not one of them. I usually do the screen capture and then add elements like captions and highlighting. Sometimes I find that I missed something and have to film extra pieces and paste them in later on. Only once I have all the video ready do I do the narration and I need a script for that (otherwise you’d hear a lot of “umms” and “likes”). Finally, I edit the timing of the slides so that the audio syncs up with what I’m demonstrating. It takes a good long while to do… a lot longer than a little HTML tutorial that I can create in a couple of hours.

There are a few studies out there that have evaluated the efficacy of screencast tutorials, but none that have really shown that screencasts are better than any other method of instruction (at least none I’ve found). Paul Pival describes one interesting study, “If you buld it, will they learn? Assessing online information literacy tutorials,” which recently appeared in College and Research Libraries. It found that students who watched their screencasts were more confident in their abilities to use the resources, but that their test scores really didn’t improve. Intuitively, I assume that screencasts would be far more effective than more text-based tutorials. I also would think that some students (though certainly not all) would find screencast tutorials more helpful than face-to-face instruction because they can go at their own pace and repeat the screencast endlessly. But I really haven’t seen any studies that show that screencasting is really an effective tool for library instruction. And I often worry about investing time and resources in something that hasn’t been empirically shown to be better than other methods of instruction. It’s not going to stop me from creating screencasts when they seem like the best option, but I wish I’m going to reserve judgment on them until I see some evidence.

Here are some resources for learning more about screencasting:

Paul Pival gave a wonderful talk on screencasting for the SirsiDynix Institute a few weeks ago. You can listen to his Webcast, Show and Tell The Easy Way – An Introduction to Screencasting, in their archive (video coming soon!) and a list of links on his blog. Also, definitely check out the Q&A he put on his blog with the questions he didn’t have time to answer during the session.

Although it’s a bit old, Screencasting to Help Your Mom, by Amit Agarwal at Digital Inspiration is a great introduction to screencasting and the major software options.

The Screencasting post at Donation Coder is extremely detailed. It describes what screencasting is and what people should be looking for in screencasting software. It also reviews, in detail, the popular (and less popular) screencasting tools.

LibCasting is a great new blog all about screencasting from Greg Notess, who is one of the very few people who has been talking about screencast tutorials for a long time.

Animated Tutorial Sharing Project (ANTS) — this project is designed to collect database screencast tutorials so that libraries are not constantly having to reinvent the wheel. A basic tutorial for Academic Search Premiere can be used by people in all different libraries since we’re all dealing with the same interface. The tutorials are stored in a DSPACE instance at the University of Calgary and can be used by people at other universities. They’ve got a big wishlist for tutorials, so if you have one that others could use, please consider sharing it. I’m definitely going to endeavor to make my screencasts more generic from now on, both to share with others and for my own sanity.

Ok, back to my red runny nose, my swollen throat and my raspy voice. Bed, not blog, sounds like a very good idea right now.

4 Comments

  1. Very timely. I’m working on my screencast for the 5 weeks to a social library course right now..and facing many of the issues you raise.

    Particularly tricky is the bandwidth one. The technology allows me to drop into Captivate video of the participants in the project I describe. I want their voices to be heard too..BUT..like you I think I’ll end up making a low bandwidth one also, with just the audio, not the video – plus no background music.

    It’s a real battle between exploiting the technology to the nth degree – because it’s fun, you can, and it gets your message across better…and creating something that everyone can access.

    I’ve been working a little differently to you. First I made some postit notes and shuffled them around on my desk to get them in order. Then I made a Captivate slide for each one. I recorded the audio each slide – not using a script, but re-doing it lots of times. If I needed to drop in an animation of the screen, I recorded it and inserted it, cut it back, then recorded the audio. I used the audio editing to cut out lots of “ums and “errs” or just plain idiot-speak. Finally, I let it sit for a few days, then aim to get the audio for each slide tighter and clearer and one third shorter, to really shrink the presentation time.

    I think I’d prefer to use something like Captivate for straight podcasting, as you can “sew” the slides together, rather than speaking in one long stream.

  2. Priscilla Finley

    Thanks, Meredith, for blogging this even under the weather! I’ve been giving a lot of thought to the development process lately while working up a project on storyboarding and the variety of narrative structures that tutorials take (linear, modular, branching, simulations or games …). I’ve been using Powerpoint to store and organize all the bits and pieces into a big outline/storyboard, (useful for sizing photos, holding digital video clips, etc.), then importing that into Captivate.

    I’d be interested to hear from anyone who has used the new Captivate release – it sounds like it offers much better support for branching and other nonlinear methods.

    Here’s a link to a very preliminary working bibliography, if anyone’s interested.

  3. At the Idaho Commission for Libraries, we’ve used Camtasia for a couple of projects. I agree that it is very intuitive. I also agree that it isn’t the answer for every project. Large file sizes and inadequate bandwidth in many areas is a drawback.

    We were very successful in using it to inform our legislators about our statewide library catalog. Conceptually, they just weren’t getting it. But when they saw it in action, it really clicked. We had to do a very important demonostration for some legislators and opted to record it using Camtasia. (We couldn’t be guaranteed the speed and quality of the equipment we’d have in the room we were using.) Camtasia worked wonderfully for this kind of presentation. For the “live” demo, we showed just the video and the presenter read from a script that followed it. We added the audio at a later date and posted it all on our website.

    A similar approach could work for demonstrating tools to library boards, commissioners, or community groups when the network resources may not be available in the meeting location.

    I think the interesting thing is that, at the time, I would never have said we were “screencasting.” As I read more about it, I realize that, in fact, we were screencasting, we just referred to it as a video.

  4. Meredith:

    You mentioned the ANTS project in your discussion about how to make screencasting a bit saner. Sharing is definitely the way.

    As a member of the ANTS project, I wanted to tell you and others, that the list of databases identified for development is a starting point. We initially identified the e-rsources listed for COPPUL libraries, but recently the project was opened beyond COPPUL (any librarian anywhere can participate in it) and as the wish list in on a WIKI we fully expect that anyone can go to the list and identify other tutorials they would like to see developed.

    Earlier in my career I spent a lot of time reviewing e-resouces that I purchased on behalf of my library and am fully aware of how many new e-resources are emerging so it only makes sense to develop a dynamic list that meets changing needs. I also am aware of how frequently vendors change interfaces, so we designed ANTS with the goal of having one librarian adopt a tutorial and keep it up to date. This was deemed to be far superior to having one librarian create multiple tutorials but not have the time to keep them up to date.

    As screencasting technology has only started to make its way into mainstream, the discussion about sharing tutorials is really only starting to emerge. There are a few projects out there, but ANTS is unique in that it allows anyone to contribute, and it creates a tool that enables people to learn what is developed on in development via the Wiki – thereby enabling people to eliminate redundancy of effort across institutions.

    We really do not need to be reinventing the wheel, so it makes sense to create tutorials that are generic enough to be used elsewhere, but at the same time allow others to customize them if they so wish. I really would encourage your readers to look at the site and volunteer to develop a tutorial. The goal is to make it a clearing house that librarians can go to for source code for tutorials.

    By the way, I really identify with your current cold medicine induced state. Been there, done that (most recently at Access 2006 when a flu hit me right before I had to speak. On the plus side, my voice dropped an octave due to the flu – so I had that Bea Arthur deep authoriative voice to speak with!)

    Carmen Kazakoff-Lane

Comments are closed