On Screencasts

Jay Fields Thoughts: Are Screencasts the Future?:

He [Geoffrey Grosenbach] sent back a few more reasons why he believes in screencasts as good teaching tools.

• Efficiency of time: It takes dozens of hours to read a 300 page book straight through. But a screencast can pack the most relevant information into an hour.
• Passive/Active: You can sit back and pick up whatever elements are interesting to you. Some people say the most valuable part is learning auxiliary shell shortcuts or workflow tips.
• Graphical/Textual: I don't know any tech publisher who pays an artist to draw helpful diagrams. Screencasts are inherently graphical and it makes sense to include a few diagrams that explain the topic better than paragraphs of text would.

I have been experimenting with doing screencasts for the class that I am a teaching assistant for. As far as I know, no other classes have been using this approach. I suspect that the HCI classes might use them but I have yet to verify that.

Like the quote above, I believe that certain things are easier explained and demonstrated through screencasts. For instance, I started the first screencast for the class to illustrate how to handle resolving conflicts during a wiki edit. For people who have never used a wiki before, handling conflicts during an edit can be a confusing task. Especially if they have no idea what to do and why a conflict would occur. And so, they tend to ignore the conflict warning and erased a previous person's edit.

After some students inadvertently destroy previous edits on the wiki, my initial thought was to write a short article on how to prevent this from happening in the future. It would have to contain numerous screenshots to actually show what was going on at each step. And then I realize how long it was going to be. Moreover, it would be hard to actually describe the conflict. Instead I opted for a screencast approach.

I opened two browser windows side-by-side and edited the same page on the wiki. I then had one browser commit earlier than the other to simulate a conflict. From there I just recorded what I needed to do to resolve the conflict. The video took about 3-5 minutes and I was able to show the real scenario and what actually happens. I did not use audio in this screencast but opted to use the "show text" feature of Quicksilver to type out important messages as the video progressed. I think it worked well.

I am also a fan of using pattern languages to describe best practices. So over this week (hopefully) I will have a set of screencast patterns done. I have already drafted the patterns map out and how each pattern related to another. I will admit that I am not expert in making screencasts but I have seen enough of them that I can tell which are good and which are confusing. I think my screencasts still fall into the category of the latter and would need some work on :)