Version 2.2 by Jon Ippolito
A screencast, or video capture, is a good promotional tool for recording demos of particular techniques, finished projects, partially working prototypes, or interactive mockups. This page explains how to accomplish a successful screencast.
You can use native screen capture using MacOS's QuickTime or Windows' Snipping Tool. ScreenFlow is a full-featured paid app that makes recording and editing screencasts a breeze. Loom has a desktop version that's limited but free, and if you're only recording the browser you can install it as a Chrome extension.
If submitting a screencast for a class, you may use shareware or free trial software only if any watermark it overlays on your movie takes up 5% or less of the screen space and isn't obtrusive. The only way to test this is to record a sample screencast, as some programs overlay the watermark after it is rendered. A published screencast should not have any logo or watermark, unless approved by your instructor.
Do not shoot the screen with a videocamera (especially a handhold one), as the shaky, off-center results will look amateurish. The only reason to break this rule would be if you needed to depict the real-time on-screen results of some performance or interaction taking place outside the computer, and are incorporating live and onscreen events in the same shot.
Depending on your computer, you may also need an external microphone for better sound. New Media instructor Matt LeClair likes to record his voiceover first, to get a good version without ums and other fumblings. He then records the video afterward by clicking along to his soundtrack, and combines them together with a movie editor.
The more involved your screencast, the more likely you'll need to edit your screencast after recording it. Most of the movie formats produced by screencast software can be opened and edited in video editors like iMovie, Final Cut, or After Effects. Screenflow includes a very convenient, built-in movie editor.
Jazzy desktop backgrounds or extraneous windows will distract your viewer from the project itself. If your screen capture application supports it, capture only the content of your target window. Otherwise:
If you have a high resolution desktop, your viewer won't be able to read details such as code, icons or small text in your screencast. To make these legible, either increase the font size using the application settings, or simply change your screen resolution (via System Preferences > Display ) to a lower value such as 800 by 600 pixels. Aim for no more than 15-20 lines of code visible on the screen.
Another approach is to zoom in to see details using Ctrl-scroll on mouse or trackpad. To enable this, visit System Preferences > Universal Access > Seeing > Zoom > Options.
If you can afford software like Screenflow, you can use its features to zoom in on the screen after you're done recording (very convenient).
It's hard for viewers to follow your explanation if they can't tell which part of the screen to look at. In the case of code, selecting usually doesn't provide enough contrast, and in some cases can actually reduce legibility. So use specialized software to call out those details, or add a highlight manually.
A simple way to add a highlight is to create a brightly colored oval or rectangle with transparent interior in a graphics program such as Illustrator or Photoshop, and save it as a transparent PNG. Then open your screen recording in a movie editor such as iMovie, Final Cut, or Premiere. Import the PNG you made and drag it over the appropriate detail in the timeline, repeating as necessary to emphasize different items on the screen.
Even a set of bullet points scrawled on the back of a napkin will help you stay on track. For more ambitious screencasts, a transcript of your voiceover in text form will help viewers use your words for reference.
Your demo should be concise and efficient. Demonstrating a specific technique needs not run longer than 30-90 seconds. Demonstrating a more involved process might run 3-5 minutes, but for longer videos consider breaking your screencast into multiple parts.
If you have an intro screen, it should not be longer than 5 seconds. Some movie applications, like iMovie, tend to cut off the last second or two of video. Make sure you let the screencast run for a couple seconds at the end after you've finished talking. (If you didn't, you can sometimes fake this after the fact using a "freeze frame" in your movie editor.)
Viewers will decide whether to watch your video within the first 10 seconds. Your voiceover should begin with one or two sentences explaining the gist of the project or demo, but then jump immediately to the sexiest part of your work. This could be a live video of someone interacting with your installation, or a screencast showing your interface responding dynamically to user input, or perhaps a demonstration of the problem you're trying to solve.
Save the code and other how-to details for the second part of your video. Viewers only want to see the nitty-gritty if you've already shown them what you did was cool in the first place.
Unless you have good reason, avoid "first I did this, then that, then that..." chronological narratives. No one's interested in your life story except you and your mom.
As you click through features--for a prototype, you can show all the ones that are finished, and hint at the ones to come--explain what the interface shows you in response. If you like, you can end with a single sentence describing the goal of your project.
If you don't want to record a voiceover, you may alternatively choose to intersplice title graphics explaining the elements of your project. Remember, you're not making a movie trailer, but explaining clearly your project's goals and accomplishments to someone who doesn't know anything about it.
You should record a trial run beforehand, to practice what you're going to say, make sure you don't run longer than 5 minutes or so, and make sure your software's working. If you do, choose a modest rendering size (such as 25%) so you don't have to wait forever for the movie to render.
If you have a built-in or separate Webcam, you can record a personal greeting ("I'm Linda Rodriguez, and today I'm going to show you how to...") to give a human face to the beginning of your screencast. That said, your talking head will be less distracting as a picture-in-a-picture in a corner of the screen, and even then is probably only useful for the first (and maybe last) few seconds.
Consider zooming into parts of the screen (described above in Preparing Your Screen) or using software like Mousepose to highlight the portion of the interface you are demonstrating. Software like Screenflow lets you add these kinds of enhancements after the fact.
Adding titles, brief bullet points, or still images to the screen at key moments can add structure and make otherwise dead sections more lively. This can be done in an external or built-in movie editor (like Screenflow or Loom).
It's best not to set your voiceover to a rockin' soundtrack, and probably best not to set it to any music whatsoever. Likewise, dazzling title graphics will distract more than help. This is not a "sound-and-image" project to show off your After Effects skills, but a straightforward demonstration of the technique or project itself.
Save your screencast as an MPEG-4 (.mp4) movie at least 600 pixels high--preferably higher--but be careful that your movie does not exceed 200MB.
If you must save as QuickTime (.mov), you'll end up with a file that's twice the size. Fortunately you can convert any movie to the MPEG-4 (H.264) codec with a free utility like Miro Video Converter. Convert a screen-based recording to WebM (.webm) and you'll shrink the size by half again.
If you're using a video editor like Premiere, a screen-only recording may come out better when saved with an "animation" setting, if your software has one. Choose a low audio quality to reduce filesize: mono audio is fine--you don't need stereo.
For a class, unless otherwise instructed, attach your movie/s to a message posted to the class conference. Other options your instructor may request include uploading it to your own Web site (such as NMDprojects.net) and posting the url to an approach in The Pool, or posting it to the free Internet Archive. (Do not post it to YouTube or in another format that can't be downloaded.)