.. include:: ============================= Preparing for Screencasting ============================= :Author: Jeff Rush :Copyright: 2007 Tau Productions Inc. :License: Creative Commons Attribution-ShareAlike 3.0 :Date: June 21, 2007 :Version: 1 :Series: Casting Your Knowledge, With Style Advice on how to get started giving screencasts, why you might want to do it and how to establish your recording studio. Then we move into planning your screencast and a few tips on using some presentation tools. .. footer:: Casting Your Knowledge, With Style .. |CLICK| image:: /home/caster/themes/screencast-800x600/NextSlide.png .. container:: handout Hello, my name is Jeff Rush and this talk, "Preparing for Screencasting", is the first in the series, "Casting Your Knowledge, With Style". Roadmap to Talk =============== .. container:: slide-display + `What is Casting and Why do it?` + `Picking a Topic` + `Building your Studio` + `Capture Settings and Formats` + `Planning the Capture Process` + `Some Tips about Tools` .. contents:: Table of Contents :class: handout .. container:: handout This talk is a gentle introduction to casting for instructors. |CLICK| We'll cover what is casting and why you might want to do it, |CLICK| how to pick a topic on which to present, |CLICK| and building your recording studio. |CLICK| Then we'll move into capture settings and formats, |CLICK| planning the capture of your presentation, and |CLICK| offer some tips on using common tools while presenting. Definitions =========== .. This one slide is marked up in a different style from the others, to show how speaker notes can be interspersed with bullet items, if desired. When speaking directly from the notes, I find it easier to collect them at the bottom of each slide. .. class:: handout Casting can be done in several formats, each with a different slant. .. class:: slide-display + `podcasting` `- audio, radio talk show format` .. container:: handout The most common form is pure audio, known as podcasting. It is a like a radio talk show, perhaps with guests. + `vidcasting` `- lectures, panel discussions` .. container:: handout Vidcasting uses a camera, pointed at someone giving a lecture or perhaps a discussion panel, and that sometimes switches or pans to a slide presentation behind the speaker. + `screencasting` `- demonstrations, tutorials` .. container:: handout Screencasting uses software to capture the changing view of a computer desktop, say during a demonstration of some software, usually with an audio overlay by an instructor explaining what is happening. + `all forms of multimedia...` .. container:: handout While they are all forms of multimedia, there are often tradeoffs in recording format and compression, presentation style, and teaching or entertainment objectives. Podcasting is more often focused on entertainment, while vidcasting shows live people and their slides, usually at an off-angle. Screencasting makes the computer screen the focal point, with emphasis on text legibility and skill learning. This talk is primarily about screencasting, but some of the advice applies to podcasting and live presenting as well. + `Further Research:` `http://en.wikipedia.org/wiki/Video_podcast` .. container:: handout For more information about casting, check out the Wikipedia article on Video Podcasting. Reasons to Cast =============== + `build a community reputation` + `show others what you do` + `leverage your effort` + `over a geographical area` + `over a period of time` + `be around when you're not` .. container:: handout There are many reasons to get into casting. Some of them are |CLICK| building a reputation within the community, |CLICK| showing family and potential employers or clients what you do and know, and |CLICK| leveraging the effort put into preparing a quality talk across |CLICK| a geographically scattered audience or |CLICK| let you reach those who cannot attend a specific speaking engagement. |CLICK| Talks also survive you and remain available when you are ill, retired or simply unavailable for some reason. More Reasons to Cast ==================== + `improve live presentation skills` + `develop ability to describe technical matters` + `less stressful than live talk` + `can critique yourself` + `can reshoot to improve it` .. container:: handout Giving casts can also |CLICK| give you the practice and confidence necessary to improve your live presentation skills, and |CLICK| develop your ability to describe technical architectures and software approaches, |CLICK| in a less stressful environment than in front of a live audience. Casting also gives you an easy way, for you and others, |CLICK| to privately critique your performance and |CLICK| can be redone repeatedly to polish the talk or update the content. Picking a Topic =============== + `tell others about something you're using` + `tackle something new and chronicle your journey` + `pick and explain a module` + `promote your project or company` .. container:: handout You've decided to give it a try, but on what topic could you present? |CLICK| 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 -- |CLICK| 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. |CLICK| As an exercise, and to help the community, pick a module from the Python standard library and work to explain it clearly and concisely. |CLICK| 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. Use a Virtual Studio ==================== + `a separate login, with preset tools and configuration` + `to cast when the mood strikes` + `more professional` + `appearance tuned for casting` + `less screen clutter may equal better compression` + `removes environmental assumptions, closer to student's setup` + `could securely grant remote access` .. container:: handout I strongly encourage you to set up a virtual recording studio within which to produce your casts. What is a virtual studio? |CLICK| Its a separate login account, within which you have prepared the tools and configuration that work best for casting. |CLICK| 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. |CLICK| 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. |CLICK| 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. |CLICK| A reduction in screen clutter may also result in better compression, as well as |CLICK| remove elements that distract or mislead your listeners. |CLICK| 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. Appearance Tips - Legibility ============================ + `consistent lighting` + `disable composite/translucency` + `check colorization of shell elements` + `font selection - desktop/applications` + `large enough` + `simple, nonstylized form` .. container:: handout Screencasting is about legibility, and there are many settings that can be tweaked to improve upon it. |CLICK| 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. |CLICK| 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. |CLICK| 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. |CLICK| And check the font you use in your shell and applications. You want it |CLICK| as large as is usable and |CLICK| without any complex serif styling. Appearance Tips - Movement ========================== + `slow down window movements` + `use window roll-ups` + `disable virtual screens/desktops` .. container:: handout 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. |CLICK| |CLICK| 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. |CLICK| 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. Appearance Tips - Spacing ========================= + `use a presentation resolution (800x600 or 800x592)` + `multidisplay arrangement (onscreen/offscreen)` `(xinerama)` + `conserve screen real estate` + `disable tool/menu bars in editors` + `disable certain bars in browsers` .. container:: handout 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 |CLICK| 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 |CLICK| 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 |CLICK| *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. |CLICK| You should also take steps to minimize waste of screen real estate by |CLICK| turning off unnecessary elements like toolbars in editors or |CLICK| browsers. Video Capture - Choice of Tools =============================== + `for Mac OSX,` `IShowU` + `for MS Windows,` `CamStudio` `or Camtasia` + `for Linux,` `vnc2swf` `, xvidcap` `, ffmpeg` .. container:: handout There are several software packages for capturing screen activity, across the various operating systems. |CLICK| For the Mac, there is the commercial package |CLICK| *IShowU*. |CLICK| For Windows, there is the free |CLICK| *CamStudio*, and the commercial |CLICK| *Camtasia*. As a Linux user myself, I haven't used those and will leave it to others to rate them. |CLICK| For Linux there are the open source packages |CLICK| *vnc2swf*, |CLICK| *xvidcap* and the lower-level |CLICK| *ffmpeg*. I'll talk about those in a future screencast devoted to screencasting under Linux specifically. Video Capture - Settings and Formats ==================================== + `capture format != delivery format` + `avoid SWF if you want editing` + `800x600` `, lossless` `, 5 frames/sec` .. container:: handout Once you've selected a capture tool, there are a myriad of possible settings. |CLICK| 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. |CLICK| 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 |CLICK| 800x600, |CLICK| use a lossless or near lossless format and, for screencasting and unlike video, |CLICK| at 5 frames per second. You don't need movie frame rates for slideshows or source code discussions. Audio Capture - What to Record ============================== + `microphone input` + `loopback of system sounds` + `second microphone for guests` + `use of VoIP/Skype for guests` + `voice, system sounds on separate channels` .. container:: handout When screencasting, you have choices to make on audio recording. |CLICK| Certainly you want to record the microphone into which you are speaking. But you may also |CLICK| 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. |CLICK| 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 |CLICK| some kind of voice-over-IP or skype facility. This can be very useful if you're using desktop sharing as with VNC. |CLICK| 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 Capture - Format ====================== + `16-bit signed` + `raw or lossless compression` + `but not high-CPU compression` + `sample rate of 8000-22050` + `format suitable for editing` .. container:: handout Audio formats for casting are pretty simple. |CLICK| The most common sample size for audio is 16-bit signed. As mentioned for video, you |CLICK| want to capture it raw or in a lossless compression format, but |CLICK| 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 |CLICK| 22050 samples/second is fine, or if you're tight on diskspace, you can go as low as 8000 samples/second. |CLICK| 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. Keyboarding in the Studio ========================= + `learn keyboard equivalents` + `use global keys to start applications` + `other uses of keys are` + `sounds` + `window arrangements` + `zooming in for emphasis` + `cursor highlighting` .. container:: handout 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. |CLICK| For your applications, learn their keyboard equivalents and park the mouse out of the way, unless you are pointing at something. |CLICK| 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. |CLICK| |CLICK| I've also programmed the *Shift-Windows* key, along with letters, to play various presentation-appropriate sound effects, such as lead-in audio. |CLICK| And special keys are useful for initiating certain window arrangements and |CLICK| zooming in for emphasis, such as *Control-+* in firefox or *Control-Enter* for certain Nvidia video chipsets. |CLICK| 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. Planning - Shooting Philosophies ================================ + `run straight through` + `short segments, perhaps sliced together` + `video first, then dub audio` + `duration?` + `one long talk or many small ones?` .. container:: handout There are several schools of thought on how to shoot a screencast. |CLICK| The most simple is grab your microphone, fire up your application and run through your entire presentation. |CLICK| Another approach, especially good for long talks, is to record short segments and splice them together later. |CLICK| 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. |CLICK| 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. |CLICK| 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. Planning - Tools to Use ======================= + `slides` + `browsing websites` + `emacs for showing source` + `ipython or IDLE for interactive coding` + `image viewer for photos, diagrams` .. container:: handout During your talk you may make use of several tools: |CLICK| For slides, perhaps Microsoft PowerPoint, Openoffice Impress or reStructuredText with the S5 extension. I'll talk more about that in the next slide. |CLICK| To visit sites for techniques or content, a browser with features and extensions for presenting. |CLICK| For reviewing source code, your favorite text editor or integrated development environment, like Emacs, tweaked for legibility and navigation features |CLICK| For interacting with the Python prompt, *ipython* or *IDLE* make good choices. |CLICK| And maybe some kind of image viewer, for diagrams or photographs. A Pitch for RestructuredText ============================ + `reStructuredText using the S5 slides mechanism` + `i.e. Simple Standards-based Slide Show System` + `benefits` + `your favorite text editor` + `focus on content, not appearance` + `converts to HTML, PDF` + `intersperse speaker/handout notes` .. container:: handout |CLICK| For slides, I'd suggest the use of RestructuredText, with the *S5* slides extension. *S5* stands for |CLICK| "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. |CLICK| RestructuredText has many benefits. |CLICK| It is written in flat text files and therefore you can use your favorite text editor. It is also platform independent. |CLICK| By doing a lot of the presentation for you, it lets you focus on content and spend less time tweaking appearances. |CLICK| In addition to producing slides, you can also make your presentation available as an HTML page or PDF document. |CLICK| 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. Planning - Emacs ================ + `readable, resizable font` + `syntax colorizing?` + `M-x setnu-mode` + `need to experiment with` + `code folding/outlining` + `jump-to-method/tags` .. container:: handout The Emacs text editor makes a good choice for talking about source code. |CLICK| 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. |CLICK| Getting all the syntax colors right can be tricky and you may find it easier to turn them off. |CLICK| 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. |CLICK| |CLICK| |CLICK| 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. Planning - Firefox ================== + `firefox` + `disable minimum font size` + `developer extensions` .. container:: handout |CLICK| To give you the ability to zoom smoothly in Firefox, be sure to |CLICK| disable the minimum font size in the preferences. |CLICK| 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. Wrapup for Now ============== + `To Review` + `Pick a Topic` + `Construct your Studio` + `Plan the Recording Process` + `Contact me:` `Jeff Rush ` .. container:: handout That concludes this part of the series. |CLICK| To review, we're covered |CLICK| how to pick a speaking topic, |CLICK| construct your studio with various tools, and |CLICK| 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 |CLICK| |CLICK| 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. .. Local Variables: mode: rst mode: outline-minor End: