Screencast Instructor Guide

This guide explains how to make screencasts so that they reach the quality standards of raywenderlich.com.

Your payment is based on this! If you do not do a good job following these guidelines, we may have to cancel your screencasts, as the quality level is very important to us. So be sure to pay close attention here.

Here’s what’s inside this guide:

What Are Screencasts?

Screencasts are for advanced developers who want to quickly pick up new skills. The idea is an advanced developer can watch a screencast over a morning coffee and learn something new. You can assume a lot of prerequisite knowledge and don’t have to hold hands.

Screencasts are for watching, not following along. Advanced developers don’t have time to follow along with a step-by-step tutorial – they just want to watch a video to get the idea, then look at some code. You should give a finished project, not a starter project to encourage this.

Screencasts are completely independent of each other. You should never assume the viewer has watched screencasts in a particular order.

Screencasts are never updated. They’re meant to be focused on the “new shiny” stuff advanced developers are excited about learning. For large important topics that need to be regularly updated, course are better.

Screencasts are meant to be quick and easy to produce. This way, we can jump on a hot topic (like an exciting new API or technology) and release a screencast very quickly.

Note: If you only remember one thing, remember this: your primary goal is to make something an advanced developer will find cool, and will learn something from!

Screencast Assignments

Screencast assignments are much more “loose” than other types of assignments on raywenderlich.com.

If you are a screencast instructor, you will be assigned a certain dates on the raywenderlich.com calendar to publish a screencast.

The rest is up to you! You get to pick the topic, and work at your own pace. This way, you have the freedom to cover topics you are passionate about, or topics the community is excited about or that are hot without having to get prior approval.

You can view the dates you are scheduled for screencasts on the official raywenderlich.com Video Tutorial calendar. If you do not have access to this, contact Ray or Christine.

Note: With great freedom comes great responsibility. You must complete your screencast recordings at least 1 week in advance of when they are due to be published so we can edit and schedule the screencast. Alternatively, you can do this yourself but it will take more time.

Please don’t miss your deadlines, as we rely on the screencasts to go out on the assigned dates.

Two Methods to Make Screencasts

There are two methods to make screencasts on our site. You can discuss with Ray which is best for your case.

A) Convert a Tutorial

The first method is to convert a free tutorial or chapter from a book on raywenderlich.com into 1 or more screencasts. This has the following pros and cons:

  • Pros: Saves time creating sample projects and researching subject
  • Cons: You are limited to the subjects we have tutorials on at raywenderlich.com and your content isn’t as unique

Note: Want a sneak peek of what’s coming? We’d be glad to set you up with early access to books and tutorials that are still in editing or otherwise not published yet.

Simply contact Ray for what you’re interested in so he can give you access. For example “I want access to all in-progress iOS tutorials” or “I want access to the in-progress Core Data by Tutorials update”.

B) Make New Content

The second method is to make your own content from scratch. This has the following pros and cons:

  • Pros: Complete control and freedom to cover what you want
  • Cons: Extra time to develop sample projects and research material

Working in Batches

Often, I like to work on a batch of screencasts at a time.

For example, I might decide to make some screencasts on Server Side Swift with Vapor, and I might come up with 10 screencasts on that. Or you might convert a tutorial into screencast form (usually a tutorial would make 2-3 screencasts).

You might find working in batches like this a bit more efficient than trying to make one screencast per subject, or one screencast at a time.

Important: Just remember that each screencast needs to be completely independent from each other! You should never make a “part 1” or “part 2”; each screencast should be valuable as an independent unit, and should be focused on something very specific. If you have trouble with this, contact Ray.

Dropbox and Github Structure

Github

You should store all of your course materials (slides, projects, recordings, etc) in Github.

Ray will create a Github repo for you to store all your screencasts in, called SC_YourName. Example: SC_BrianMoakley. Ask him if he forgets to do this :]

You should use the following directory structure in Github:

  • For Research: In phase 1, you’ll place any experiments that you make here.
  • For Student/Pre-Recording: In phase 2, in a subdirectory for each screencast, you will place the sample project for that screencast. In phase 4, you may split each of these into multiple screencasts if necessary.
  • For Instructor: In phase 3, in a subdirectory for each screencast, you’ll add the script for that screencast.
  • For Student/Recording: In phase 5, in a subdirectory for each screencast, you’ll make new projects so they match up to exactly what you do live.
Note: As mentioned above, inside each of these folders, for each screencast you make, you should create a subfolder like YourScreencastName where you put the materials for that screencast. Example: CreatingFrameworks.

Dropbox

When you’re ready to record, create a folder called SC_YourName.

Then create a subdirectory for each screencast here, with the same name you used earlier (like CreatingFrameworks). Make sure you have audio.m4a, camera.mov, demo.mov, and voiceover.m4a in this folder.

Phase 1: Research Phase

A) If you are converting a tutorial

During the research phase, you should go through the tutorial step-by-step as a reader and make sure you fully understand the content presented in the tutorial.

That’s it! You don’t need to do more research than this; the idea is the tutorial author already did the research, so you can save time in this phase and skip further research.

B) If you are making new content

If you are making new content, you may know the subject inside and out. If that is the case, you’re set.

But often, you may be new to a subject or missing some bits. If this is the case, you should do some research on the subject. This consists of the following:

  • Watching any relevant WWDC videos
  • Reading any official Apple documentation/sample projects on the subject
  • Reviewing any tutorials or books on raywenderlich.com related to the subject
  • Reviewing other blogs/sites to see what they wrote about the subject
  • Reviewing any books related to the subject
  • Reviewing open source software (such as cocoacontrols.com) related to the subject
  • Reviewing any popular apps that use technologies related to your subject, to see how it is used in practice
  • Search on StackOverflow to see what common questions are related to your subject
  • Asking Ray and other iOS developers you know for what they’d like to see in your screencast
  • Playing around with some code demos trying out things with your subject – consider this throwaway code, just for testing

Your goal is to make sure you thoroughly understand:

  • The material of your subject, at a deep level
  • What Apple says about your subject
  • How your subject is used in practice in real iOS apps
  • What people want to know about this subject (common questions/ways its used in controls/etc).
  • What other people are saying about this subject

Although the research phase can be time-consuming, usually you can make multiple screencasts based on the things you have learned here.

Phase 2: Sample Project Phase

A) If you are converting a tutorial

You may think if you are converting a tutorial, you are done with this phase, since it comes with a sample project already!

Well, yes and no. You can (and should) use the same sample project, however the problem is usually a 4,000 word tutorial contains too much content to fit into a 6 minute screencast (with a script of 1,300 words) so you need to split the tutorial up a bit and do some thinking about how to do this.

  1. List out the 2-3 most important techniques covered in the tutorial of interest to advanced developers. A written tutorial or chapter on our site covers too much information to cover in a single 10-minute screencast, so break it into smaller chunks. And drop anything that is commonly known or not interesting to advanced developers.
    • For example, in this iOS Frameworks tutorial, the two most important topics are How To Make a Swift Framework and How To Make a CocoaPod. It also covers “How To Create a Github Repository” because it’s a step-by-step tutorial, but that should be already known by advanced developers so isn’t necessary to include in a screencast that you watch.
  2. Determine most common starting and ending point the average reader would have for each case. Ask yourself – if a user was trying to do apply your subject in their own projects, what would their typical situation be? Note this could be different than what the tutorial did!
    • How To Make a Swift Framework: Typical Start: User has existing Swift code. Desired End: Use has moved the code to a framework so they can reuse the code in multiple projects.
    • How To Make a CocoaPod: Start: User has an existing Swift framework in Github. Desired End: User has published the framework as a CocoaPod so it’s easy for other developers to use.
  3. Build the appropriate starter/final project to match the above. You can base these on the tutorial code but it may be slightly different (i.e. you might skip or add some steps so you can focus on critical bits only).
    • How To Make a Swift Framework: Starter: ThreeRingControl integrated directly into Phonercise. Finished: ThreeRingControl now extracted as a separate framework used by Phonercise.
    • How To Make a CocoaPod: Starter: ThreeRingControl framework, stored on GitHub. Finished: ThreeRingControl now has a podspec and is used by a Podfile in Phonercise (by name, not :git link).

B) If you are making new content

If you are making new content, just make a sample project for the screencast. Typically you’ll have a starter project (even though you won’t give it to the user), and you’ll add some code to demonstrate the main topic, and then you’ll release the finished project to the viewer.

If I am making multiple screencasts on a subject, I’ll often make multiple sample projects at this point, to demonstrate each piece I want to make a screencast for. However often I get it wrong and have to split things even further later – see Phase 4 (split script phase).

Phase 3: Script Phase

Once you have your sample project ready, the next phase is to write a script for the screencast.

In a way, this is very similar to writing a tutorial for our site. You walk through step-by-step of building up the project, explaining things along the way.

There are a few differences to keep in mind:

A) Instructor vs. Code

When making screencasts, sometimes you want the instructor (you) to be visible, and sometimes you want the code to be visible. In general:

  • The instructor should be visible at the start/end of each video, and any “interludes” that you’re explaining theory in the middle (and not typing code).
  • The code should be visible when you’re showing the user the steps to build up the project.

Example

At 2:09 in my first Server Side Swift with Vapor screencast, I wanted to give a little side note about what the Droplet class is. It was better to show the Instructor for this, because watching someone talk is more fun than watching a screen where nothing is moving or happening. In general, if you’re doing something, show the Code; if not show the Instructor.

B) Code snippets

In written tutorials, we describe what we’re going to do, add the code, then describe what it did.

In screencast scripts, we describe what we’re going to do, describe what we’re doing, then add the code (which we just described). The video editor will make it so that you demonstrate the code as you read the proceeding paragraphs.

Important: When editing your screencast, the editor will attempt to combine the paragraphs preceding your code with you typing the code as closely as possible. For best results, be sure to phrase things as-if you were typing the code and describing it bit-by-bit as you type.

You should also keep in mind exactly what you are going to be doing in the demo, and comment appropriately. Always think about the end result!

Example

This is an snippet from my Server Side Swift with Vapor script. Note how in the example below, I describe the lines of code one bit at a time, as-if I would if I were explaining the code as I typed it out.

“To do this, simply pass in your path as usual, but for any path you want to use as a parameter, put the type that you are expecting. In this case, we want an int so we just put Int.self. If we try this out, we see it works, and even better – if we try to put something that isn’t an Int, Vapor will automatically detect this and throw an error, saving us from having to do that type checking.”

drop.get("beers", Int.self) { request, beers in
  return try JSON(node: [
    "message": "Take one down, pass it around, \(beers - 1) bottles of beer on the wall..."
  ])
}

C) Introduction and Conclusion

The introduction of each video should have the following format (130 words or less):

“Hey what’s up everybody, this is Ray. In today’s screencast, [briefly describe what you’re going to do].”

The conclusion of each video should have the following format (130 words or less):

“Allright, that’s everything I’d like to cover in this screencast. [Then briefly describe what the reader learned, where to learn more, and make a humorous joke, pun, or comment to end things.]”

Introduction Example (72 words)

“Hey what’s up everybody, this is Ray. In this screencast, I’m going to show you how you can securely register users for your web app over SSL.

Specifically, we’ll send the username and password over a SSL connection, and store a hash of the password in a database. I’ll show you how you can set up a self-signed certificate for testing, and how to configure Vapor to use it.

Let’s dive in!”

Conclusion Example (114 words)

“Allright, that’s everything I’d like to cover in this screencast.

At this point, you should understand how to register uses for your app over SSL.

Now that we can register users, the next obvious step is to let them log in. That’s the subject of the next screencast.

Speaking of registration, It reminds me of this one time that a programmer was working on an app for a cash register. He tried it out on a gallon of milk, and it worked fine. But then he tried it out on some cigarettes, and he got an error. After much debugging, he found out the cause – it was a sin tax error. Allright – I’m out!”

D) Full Example

The easiest way to understand how to write a script is to watch my Server Side Swift with Vapor screencast video as you read the script that goes along with it.

Phase 4: Split Script Phase

Remember screencasts are meant to be extremely short; 6 minutes or less, ideally, but definitely no more than 8 minutes.

If you’re anything like me, on your first attempt you will have too much in your script to fit within that timeframe. This phase is to split your script into multiple screencasts to resolve this.

Here is how to do this:

  • Check length. Scripts should be around 1,300 words or less (1,700 words max). The word count should be done with a standard word count, including code snippets in your script. At 1,300 words your screencast should be 6 minutes; at 1,700 it should be 8 minutes.
  • Shorten intro: It’s easy to make your intro too long. Keep it 130 words or less if possible and dive into the content.
  • If too big: If your script is too big, you can either cut content and simplify, or you can try to find a way to break it into two screencasts. If you do two screencasts however, you need to find a way to focus each screencast on an independent stand-alone topic. In other words, you never want to have a “part 1” and a “part 2” in screencasts.

Once you’ve figured how how you want to split your content, break it into independent scripts each with their own intro, conclusion, and projects.

In my personal experience, I usually have to split my scripts into 2-3 parts at this phase because I tend to make them too long, but your experience may vary.

Phase 5: Recording Phase

Once you have the script done, it’s the easy part – recording! There are three things you have to record: the demo, the demo voiceover, and the camera.

1) Demo setup

First prepare your computer for recording:

  • Check desktop resolution. Set desktop resolution to 1920×1080
  • Check Xcode font. In Xcode Preferences \ Fonts & Colors \ Source Editor, set to Presentation
  • Check wallpaper. Set desktop wallpaper to a boring gray color to avoid distraction, and make sure desktop is 100% clean (no files).
  • Check toolbar. Install this app to keep your toolbar free of icons and junk: Bartender
  • Adjust microphone. Put your USB microphone right above your keyboard – you want the sound of you typing to clearly pick up.

Then record:

  1. Start recording. Run QuickTime Player and go to File\New Screen Recording, make sure your USB microphone is selected, and start recording.
  2. Record demo. Follow along with your script, adding the code one bit at a time, as you have it there. If you make a mistake, say something like “Hey editor – I messed up here, hang on… OK fixed, please rewind to [wherever]” so they know what to do.

Save this file in Dropbox under “For Videos” as demo.mov.

3) Record Voiceover

  1. Adjust microphone. Put your USB microphone next to your mouth now.
  2. Start recording. Run QuickTime Player and go to File\New Audio recording, make sure your USB microphone is selected, and start recording.
  3. Record voiceover. Read your script (except for the parts where you’ll be on camera). If you make a mistake, say something like “Hey editor – let me say that again.” and repeat the sentence.
  4. Review voiceover. Listen to the voiceover after you finish recording and make sure all is OK.

Save this file in Dropbox under “For Videos” as voiceover.m4a.

4) Camera Setup

First prepare yourself for recording:

  • Check personal grooming. Check your hair – make sure it doesn’t look dis-sheveled or in need of a haircut. If male, check your beard – make sure you don’t look like you need to shave.
  • Check shirt. Make sure you have a shirt that look nice – not sloppy. You don’t have to wear the RW shirt for screencasts as long as you look nice.
  • Check camera focus. Triple check your camera focus. If you aren’t properly focused you’ll need to re-record.
  • Check background. Make sure you have a nice background for recording. It should be a plain (or nice looking) wall with a framed image to the side of where you’ll be standing. See example from Ray and example from Sam.
  • Adjust microphone. Adjust the microphone to be close to where you will be speaking.

Then record. Note you will use your USB mic to record your voice, and the camera will be for video only. These two tracks will be combined in editing.

  • Start recording (on PC). Run QuickTime Player and go to File\New Audio recording, make sure your USB microphone is selected, and start recording.
  • Start recording (on camera). Then start your camera recording, and go through the parts on the script where you are on camera. Note you can repeat the same line multiple times in a row until you get it right.

Save the PC audio recording in Dropbox under “For Videos” as audio.m4a, and the video camera recording as camera.mov.

Phase 5: Editing

For your first few screencasts, you will do your own editing. This way, you can have a good understanding of what video editors do for you, and can make sure to make your content accordingly. Ray will train you up on how to do this – be sure to have Adobe Premiere Pro installed and working on your machine in preparation.

After that, a video editor will do your editing for you, to save you some time. Remember though, you need to deliver your screencast files to a video editor 1 week before publication in order for them to be able to edit it in time.

When you are done, create a Trello card for each screencast you made, and add a note about where the editor can find the required files in Dropbox for the screencast.

That’s it – happy screencasting! :]