Hello, my name is Jeff Rush and this talk, "Preparing for Screencasting", is the first in the series, "Casting Your Knowledge, With Style".

This talk is a gentle introduction to casting for instructors. We'll cover what is casting and why you might want to do it, how to pick a topic on which to present, and building your recording studio.

Then we'll move into capture settings and formats, planning the capture of your presentation, and offer some tips on using common tools while presenting.

There are many reasons to get into casting. Some of them are building a reputation within the community, showing family and potential employers or clients what you do and know, and leveraging the effort put into preparing a quality talk across a geographically scattered audience or let you reach those who cannot attend a specific speaking engagement.

Talks also survive you and remain available when you are ill, retired or simply unavailable for some reason.

Giving casts can also give you the practice and confidence necessary to improve your live presentation skills, and develop your ability to describe technical architectures and software approaches, in a less stressful environment than in front of a live audience.

Casting also gives you an easy way, for you and others, to privately critique your performance and can be redone repeatedly to polish the talk or update the content.

You've decided to give it a try, but on what topic could you present?

As a programmer, you're undoubtly already using some nifty tool or module. While its fresh in your mind, give a walkthrough on how to use it or the benefits it gives you.

Or perhaps there is something you've been meaning to learn -- take notes on your journey and then talk about what you discovered and when.

And we all know that when you teach something to others you learn it better yourself. As an exercise, and to help the community, pick a module from the Python standard library and work to explain it clearly and concisely.

Also many of us are affiliated with an open source project or company. A screencast is a excellent opportunity to recruit others to join you and get involved in further development.

I strongly encourage you to set up a virtual recording studio within which to produce your casts. What is a virtual studio? Its a separate login account, within which you have prepared the tools and configuration that work best for casting.

Such a studio allows you to crank out a cast when the mood strikes you, without having to do a lot of preparation each time.

It makes you appear more professional, with the removal of personal elements, such as wallpaper, bookmarks and instant-messaging popups, from the desktop that others see.

And the studio desktop can be preset with fonts, colors and mouse pointers selected for readability, audio at precalibrated levels, and any screensaver or power management display blanking disabled.

A reduction in screen clutter may also result in better compression, as well as remove elements that distract or mislead your listeners.

Last, the use of a separate login allows you the option of granting realtime access, via VNC or some other tool, to a small class of listeners or a guest presenter.

Screencasting is about legibility, and there are many settings that can be tweaked to improve upon it.

Contrast is important, as is a consistent lighting scheme. Choose light text on a dark background or dark text on a light background, but don't use different schemes in different applications. Also, a consistent scheme will let you choose mouse pointer graphics that work everywhere on the screen. I recommend dark text on a light background, for a brighter overall appearance that will suit more viewers.

Be sure to disable any composite/translucency settings on your desktop. Show-Through graphics may look cool, but can be hard to read in video recordings and certainly will not compress well.

Review your shell applications and check them for good color selection. Some shells colorize the prompt itself, and commands such as "ls -l" will apply colors to directory entries according to certain rules. Also check for clear, readable source highlighting in your preferred text editor or integrated development environment.

And check the font you use in your shell and applications. You want it as large as is usable and without any complex serif styling.

Movement about the screen is a key part of a screencast. When you're watching a power user operate the keyboard and mouse, it can sometimes be hard to follow along as windows zing and zoom around the screen. You're never sure which key was pressed.

One thing that can help is to animate and slow down the various window movements. Many desktops provide some way to do this. For example, under Linux using the Enlightenment desktop, you can open windows, minimize and window-shade scroll them slowly. Here is an example.

(insert demonstration of opening a shell window, window-shading it and unwindow-shading it)

I recommend use of window-shading, as it makes it easier to see where a window went, and when you're getting it back. The other ways of using Alt-Tab or some special window selector aren't standard and so may not familiar to everyone.

Unless you're using them in your talk as alternate presentation areas, be sure to disable multiple or virtual desktops. Accidentally bumping the borders of your screen and suddenly switching desktops can be disconcerning to viewers.

The spacing on your screen is a scarce resource. You want display elements as large as possible for readability, but you also need everything to fit.

To reduce the size of the final video and have it fit within a browser window it is common in screencasting to use a smaller size of screen, such as 800x600. I use the slightly shorter 800x592 as some screen recorders can achieve better compression when both dimensions are multiples of 16. Some video distributors transcode that to a delivery format of 640x480 which also are multiples of 16, so starting with multiples of 16 removes some sources of distortion.

Now 800x600 isn't much room to work, so it can be useful to adopt a multidisplay setup. On a laptop, you can often set things up so that the LCD display and an external CRT monitor are side-by-side displays onto the same logical screen. Under Unix, this capability is called xinerama. You can then set your screen recorder to capture only the CRT monitor portion. Such an arrangement lets you treat the LCD display as an off-stage preparation area, from which you can drag windows or click on iconbars when needed during a talk. This lets the on-screen area be focused on the point being discussed without being cluttered with screen elements not currently being used.

You should also take steps to minimize waste of screen real estate by turning off unnecessary elements like toolbars in editors or browsers.

There are several software packages for capturing screen activity, across the various operating systems.

For the Mac, there is the commercial package IShowU.

For Windows, there is the free CamStudio, and the

commercial Camtasia.

As a Linux user myself, I haven't used those and will leave it to others to rate them.

For Linux there are the open source packages vnc2swf, xvidcap and the lower-level ffmpeg. I'll talk about those in a future screencast devoted to screencasting under Linux specifically.

Once you've selected a capture tool, there are a myriad of possible settings.

The first thing to realize is that the capture format does not have to be the same as the delivery format. Sometimes, especially if you have a slower system where advanced processing on the fly might interfere with your presentation, you want to capture in an uncompressed or minimally compressed format, and then postprocess it into something smaller afterward.

Another reason for capturing in a minimal format, is that it can make postprocessing easier, since more of the original signal is retained.

And you don't want to capture in the flash SWF format if you intend do any editing as few if any tools support it.

In summary, you want to capture in something like 800x600, use a lossless or near lossless format and, for screencasting and unlike video, at 5 frames per second. You don't need movie frame rates for slideshows or source code discussions.

When screencasting, you have choices to make on audio recording.

Certainly you want to record the microphone into which you are speaking. But you may also want to capture any sounds played by your computer, to give clues to your listeners on what is happening onscreen, or because you are demonstrating multimedia processing of some kind.

Some sound cards have an internal loopback bit that can be set in the audio mixer, that cause the recording process to pick up a mix of the microphone input and audio output. For others, you'll need some kind of external audio mixer hardware that plugs into the microphone input of your system.

If you plan to do interviews or shared demonstrations with another person, you may also want a second microphone. You'll need that external mixer hardware to merge it into the signal. Or if your guest isn't physically at your keyboard, you can use some kind of voice-over-IP or skype facility. This can be very useful if you're using desktop sharing as with VNC.

One last tip. In my case, since microphones are often single-channel, I capture my voice and the system sounds on separate left-right audio channels. This makes is easy to postprocess one or the other.

Audio formats for casting are pretty simple.

The most common sample size for audio is 16-bit signed. As mentioned for video, you want to capture it raw or in a lossless compression format, but avoid compression that puts a strain on your CPU if possible.

For simple speech, you don't need DVD-quality audio sampling rates. Using a rate of 22050 samples/second is fine, or if you're tight on diskspace, you can go as low as 8000 samples/second.

Use an audio format suitable for editing, such as simple .wav.

MP3 and Ogg Vorbis for fine for delivery but not ideal for editing, because of their lossy nature.

While giving your talk, you'll need to activate various presentation elements. While many of us are used to using a mouse for this, the mouse movements can be distracting.

For your applications, learn their keyboard equivalents and park the mouse out of the way, unless you are pointing at something.

Define global keys to start applications. I've programmed my Windows key, in combination with letters A-Z, to kick off specific programs, such as Windows-T for a terminal, Windows-B for the browser.

I've also programmed the Shift-Windows key, along with letters, to play various presentation-appropriate sound effects, such as lead-in audio.

And special keys are useful for initiating certain window arrangements and zooming in for emphasis, such as Control-+ in firefox or Control-Enter for certain Nvidia video chipsets.

Some desktops have features for the vision-impaired that are useful for presentations. Under Gnome, you can enable a setting where tapping the control key causes a visible ripple or effect around the mouse pointer, to draw a viewer's attention to a specific spot.

There are several schools of thought on how to shoot a screencast.

The most simple is grab your microphone, fire up your application and run through your entire presentation.

Another approach, especially good for long talks, is to record short segments and splice them together later.

And then there are those who choose to focus first on what they are doing rather than try to talk and operate software at the same time. They shoot just the video, and then go back and dub the audio track onto it. You may though need to leave enough time in the video to say everything you going to say or do extensive editing to overlay the audio.

Regardless of approach, you need to consider how long to make your talk. Many I've seen on the net lately are just 5-10 minutes long, for quick demonstrations. If you're presenting a complex topic, you'll obviously need something much longer. One benefit of casting is that it can be as long as you need, and unlike face-to-face presentations doesn't have to fit into a fixed timeslot.

Of course, a long video will be a much larger file, and if listeners cannot stream the video, some will be reluctant to download a huge file just to check it out. In that case, provide shorter chapters or a single talk preview video to get them interested.

During your talk you may make use of several tools:

For slides, perhaps Microsoft PowerPoint, Openoffice Impress or reStructuredText with the S5 extension. I'll talk more about that in the next slide.

To visit sites for techniques or content, a browser with features and extensions for presenting.

For reviewing source code, your favorite text editor or integrated development environment, like Emacs, tweaked for legibility and navigation features

For interacting with the Python prompt, ipython or IDLE make good choices.

And maybe some kind of image viewer, for diagrams or photographs.

For slides, I'd suggest the use of RestructuredText, with the S5 slides extension. S5 stands for "Simple Standards-based Slide Show System" and was created by Eric Meyer. S5 itself is unrelated to Python but has had support for it added to the docutils module, which implements RestructuredText parsing.

RestructuredText has many benefits. It is written in flat text files and therefore you can use your favorite text editor. It is also platform independent.

By doing a lot of the presentation for you, it lets you focus on content and spend less time tweaking appearances.

In addition to producing slides, you can also make your presentation available as an HTML page or PDF document.

The S5 extensions also allow you to sprinkle notes between slides that don't show up in your presentation but are available in the HTML/PDF formats.

The Emacs text editor makes a good choice for talking about source code.

Be sure to select a font that is readable for your screen size and color. For focusing on select code portions, learn how to quickly zoom in and out.

Getting all the syntax colors right can be tricky and you may find it easier to turn them off.

There is a useful Emacs macro setnu-mode that, by enabling line numbers along the left margin, lets you verbally refer to portions of code by line number.

And the code folding, outlining and support for source tags in Emacs may be useful in your talks as well. I myself need to check these out more fully.

To give you the ability to zoom smoothly in Firefox, be sure to disable the minimum font size in the preferences.

And there are many extensions for Firefox that may be useful in talks, from examining the webpage source during a webserver talk, to standards compliance testing. I hope to cover some of these in future talks.

That concludes this part of the series. To review, we're covered how to pick a speaking topic, construct your studio with various tools, and plan the recording of your talk.

Look for the next talk in this series, in which we cover the actual screencasting process itself, followed by a third talk on what tools I'm using for casting under Linux.

Thanks for listening and I hope some of you will be motivated to get into casting.

I hope to refine and expand this talk with feedback from listeners, so please let me know where I get it wrong and how it be improved.

The slides and script are available under the Creative Commons Attribute-ShareAlike license, for you to reuse or change.