So I said in the first post in this series that I would start in with the workflow and tool set I use for making the different kinds of screencasts I do. But there’s a “square one” to the workflow that is common to all of these and needs to be discussed first:
We're sorry. Something went wrong.
We are unable to fully display the content of this page.
The most likely cause of this is a content blocker on your computer or network.
Please allow access to our site, and then refresh this page.
You may then be asked to log in, create an account if you don't already have one,
or subscribe.
If you continue to experience issues, please contact us at 202-466-1032 or help@chronicle.com
So I said in the first post in this series that I would start in with the workflow and tool set I use for making the different kinds of screencasts I do. But there’s a “square one” to the workflow that is common to all of these and needs to be discussed first: Planning. If you dive into any project without careful planning, you might end up with a roaring success -- but more likely you will come up with nothing worth sharing. Screencasts, being a kind of project, are no different. Careful work on the front end greatly simplifies the work on the back end and improves the overall results.
The planning stage of a screencast for me has five distinct parts.
1. Settle on a small number of coherent main ideas to discuss. I set a limit on the length of all my screencasts at 10 minutes. This is because my main inspiration for screencasting, Salman Khan, does this, and because there’s a 10-minute limit on YouTube uploads. But also, it’s well-known that audience attention to presentations drops off a cliff after about 10 minutes of sustained effort. Within that limit, you can only hope to address so much. So within the main body of material I am trying to teach through screencasting, I try to cluster together small clumps of topics that mutually support each other and stick ONLY to those topics. For example, this MATLAB screencast covers three MATLAB commands that are thematically related:
There was going to be a fourth topic, the FPRINTF command, included with that screencast, but it’s considerably more complicated than the other three and so I made a separate screencast just for it. My rule of thumb is to cover no more than four main ideas in a single 10-minute screencast. If you have more than that to cover, break things up into multiple screencasts of shorter length. Your audience’s attention spans will thank you, and it’ll make it easier for users to find that one part of that one video that they really need.
ADVERTISEMENT
2. Decide on a minimal number of things to say about each main idea. By the same token, stick to just the most important things that your audience needs to know about each main idea and plan an outline accordingly. For example, in making the Input/Output Commands screencasts I linked above, I talked about three commands -- INPUT, MENU, and DISP. The outline for this looked like:
INPUT: Lets users enter input; stores input as a variable; default variable type is DOUBLE; pass an option ‘s’ for string.
MENU: Creates GUI menu with title and buttons for choices; pass it string arguments for the title and button labels; returns integer values depending on the button clicked.
DISP: Displays contents of a variable; nontrivial formatting is tricky or impossible; simple but limited.
There’s more I could say about each of those commands, but these are the most important things that users should know right now. When there’s much more to say, I give suggestions for places to look for more info.
3. Try to come up with a single unifying example that connects the main ideas. This doesn’t always work, but if you choose your screencast topics so they are coherent main ideas, you should be able to find a good instantiation of those ideas that shows all of them in action and in comparison to each other. The Input/Output screencast above does this by using INPUT to gather numerical data on tests scores and then DISP to spit out the average of those scores. A single unifying example makes the main ideas easier to remember because it shows how they fit into an overall framework, rather than presenting them as discrete and disconnected topics.
4. Plan out a rough script to follow. There are differing opinions about scripts when screencasting. Some folks say you should script out every word and just read off the script. Others clearly come in with nothing more than a general idea of what they want to do and then just wing it. The former approach usually ends up with a polished, professional screencast but which can come off as cold and impersonal. The latter approach is more fun to follow but can contain false starts, dead ends, and speech artifacts (“Um... er... ah...”) that can frustrate some people.
I used to be on the “script it all out” end of the spectrum, and my earliest screencasts show it. They are tight, precise, and rarely a word out of place. But I found I was spending an hour scripting out a 5-minute screencast, and I just don’t have the time for that when I am cranking out 50 minutes of screencasts a week. So lately I’ve moved more toward a “detailed outline” model. I will take the rough outline (with a minimal number of essential things to say about a small number of main ideas) like I made above and flesh it out with specific examples that are written out and tested for correctness in advance, and maybe a few important turns of phrase I want to use -- then follow the outline, but make up the words as I go. This is what I mean by a “rough script”. I will usually write up the rough script by hand on a piece of paper and have it sitting in front of me when I record. For tough passages, I will still script things completely out. For instance, in the FPRINTF screencast I am going almost entirely word-for-word off a prepared, fully written-up script because when I tried a rough script on that stuff it was coming out garbled and wrong.
I would suggest that new screencasters should still script things out completely until you are comfortable with the recording process, which we have not even started discussing yet. It’ll build your confidence because you don’t have to worry if the words are coming out right.
ADVERTISEMENT
5. Prepare your space. Finally, before recording, prepare the space you are going to use. I usually make my screencasts in my office at work, and my ritual is:
Quit all noise-making computer programs, like anything that makes an alert sound -- email clients especially. Your audience doesn’t want to hear you get new mail while they’re learning from you.
Clear off the desk in front of me so that there’s room for my rough script and mouse. Also a clean desk will give you a clear head.
Go fill up my water bottle, because inevitably when I screencast I will start coughing or get something caught in my throat.
Close the office door and hang out my special sign that says, in bright green Sharpie, DO NOT DISTURB -- VIDEO RECORDING IN PROGRESS.
Turn the iPhone on silent mode and turn the ringer off on the office phone.
Get out and plug in any gear I need to use and make sure it works.
Set up the computer desktop -- remove all unwanted stuff just as I would my physical desktop and prepare any software “props” -- presentations, graphics items, etc. -- I will need.
Then, when everything’s in place, you’re good to go! You have a rough script that gives you just enough scaffolding to give a human-sounding but professional screencast on the essential need-to-know items relating to a minimal number of big ideas, and all the pieces are in place. So now we record -- but how? We’ll get to that next time.
Robert Talbert is a mathematician and educator with interests in cryptology, computer science, and STEM education. He is affiliated with the mathematics department at Grand Valley State University.