Screencasting is a wonderfully unique tool to teach others in the technical field. Screencasting is the process of recording code on your screen, and pairing that with audio recordings by editing these together.
Over the course of BackboneRails, I've gone many iterations of creating screencasts. In this article, I will share 7 tips and tricks for how to produce screencasts of your own.
While creating screencasts has been one of the most rewarding things I have ever done, it is by far also the hardest. When watching screencasts, it's easy to think that you could record your own in a very short amount of time - but actually creating one is extremely challenging and time consuming. Production on even a short screencast is like traveling upriver to Colonel Kurtz.
Screencasts stand apart from written tutorials and blogs because it is a permanent media. Once it's released, it is very difficult to update the content. This means screencasting requires a lot of planning, effort and foreknowledge on your part.
But getting to the end and releasing is an extremely gratifying moment. You've created something from nothing, hopefully made a positive impact on others, and ultimately became a better developer during the process.
Before you begin recording you should know a little bit about your constraints and audience. Here are some questions you should be able to answer.
These answers depend on having a strong understanding of your audience. Before I began any planning for BackboneRails, I spent a lot of time becoming familiar with developers, and understanding their concerns. I spent a lot of time in the
#Marionette channel on IRC just having discussions with developers and asking them questions honing in on topics.
You'll also want to be familiar with your personal goals for creating screencasts. It will help to answer these questions.
Ultimately for BackboneRails, I knew that there was a need for material that covered building large-scale applications using Backbone.js. I had trudged through months of teaching myself and discovering many scalable and reusable pattners. I wanted the community to have access to tutorials in an affordable and fast format that they could easily digest.
I also wanted to learn the technologies involved in video editing. I have a passion for movies and wanted to dig deeper into the recording and editing process.
The secret to any good book, movie, blog, or talk is telling a story. Screencasting is no different. Choose a topic with a well-defined story in mind. There should be an introduction, a discovery, a struggle, and a conclusion. Maybe you can identify with a specific pain point of your audience. This kind of "conflict" should be written into the story of your screencast.
With a well defined audience, goals, and subject, you can now start structuring the details of your screencast. Write an outline that breaks down every single part of your screencast. This outline will guide your on-screen coding and serve as the backbone for your script (yes, script, we'll get to that later).
Creating an outline will highlight and expose any problems before investing the time it takes to produce an entire screencast. It will also help you decide which parts of your screencast may require diagrams, animations, documentation, or anything outside of just recording code.
Whatever you do, don't write out every word of what you want to say yet - even if you're excited and want to write a lot of detail. Writing a script prior to recording will end up in disaster. It's similar to jumping into coding a difficult problem before sitting down and thinking through the larger parts needed for the architecture. Stick to a lean outline and don't commit to too many details.
What you decide to record will become the majority of your screencasting "product". It will be what makes or breaks its success. Ironically though, you will spend the least amount of time on recording code. I spent 5 1/2 hours recording the coding for Episode #7, which represented 3% of the total time put into the screencast. This was a huge revelation to me.
Take advantage of this! Do not sell your code short. This is where you should invest as much energy as possible.
You'll want to make your code recordings as flawless as possible. Write out your code first, without recording - and make sure it works! That's why having an outline is helpful - you'll have already determined how each part will fit together. You want to have the debugging process done before you hit the record button. This will save you countless numbers of hours in editing later.
Once you are sure your code is solid and complete, begin your recordings by sectioning them into small, concise, bite sized pieces of code.
Using a second monitor to display your completed code can be instrumental in giving you a goal to code towards. This helps prevent making petty mistakes which ruin a take, like simple syntax errors. It's okay to roll back to your last correct recording in case of a major error. It's much easier to throw away a few minutes of coding than it is to try to fix it in post-production (during editing).
Not everyone will be familiar with your code editor and using keyboard shortcuts during recording can be confusing to viewers. To viewers, things will appear to just happen by magic on the screen unless you explicitly state and display the keyboard shortcuts you are using. I tend to avoid using keyboard shortcuts altogether. Instead I opt to use context menus and explicitly use my mouse to click buttons. The viewer will be focused on the pointer / cursor.
Likewise, it's a good idea to pay attention to your navigation in your code editor. If you're moving quickly between tabs will the viewer be able to follow? Do everything slowly - you can remove frames or speed up the movements in editing later if needed. But it will be incredibly difficult, if not impossible, to add new frames to slow things down in editing. It's always better to have too much footage than too little.
Don't even think about recording audio with your code. Focus on coding perfectly. You can easily miss vital pieces of code if you are focused on explaining the code while you're recording. Writing and recording a script later will result in a much fuller, more compelling screencast. And nobody likes to hear you clicking away on your keyboard anyway.
With the code recorded, you'll want to assemble the rough cuts into your video editor of choice and begin trimming it down. Don't worry about small details or typo's right now, just focus on the overall story.
Throw away major mistakes or sections of code that don't lead to a clear conclusion. Annotate each of your clips, fitting them to your outline. Leave yourself notes if its not 100% clear. It's not unreasonable to throw away more than 50% of your total recorded code. The idea here is to slice away the unusable code and start molding the general story of your screencast. When I'm rough cutting I can rough cut about 10 - 20 minutes of video an hour. Any continuity issues will come to light here.
You will identify inconsistencies in continuity during this phase. In movies, if shots are taken out of sequence, this can result in strange continuity issues. Example: in one camera shot, the coffee cup is empty and then in the very next camera shot, the coffee cup may be full. It's caused by multiple takes of filming and oversight when recording. If you find any more than minor issues, its much easier to re-record the sequence. That's why recording well on the first try is really important. If you have to go back to re-record, you'll have to recreate your environment so there aren't any continuity issues between your new recording and your older recording. Open up every tab as before and setup all code bits to match earlier sequences. This is a better approach than trying to cover up these details in editing later.
With your rough cut in place you can now start to write your script. It is important you write a script for several reasons. For one, ad-libbing will only go so far. If you try to ad-lib you will inevitably cause yourself more work than writing a well prepared script. Editing is the longest process and anything you do to push more work down to editing will increase the overall screencasting process. So save yourself a lot of time, and instead of needing to fix your um's and uh's, write a script using proper vocabulary. Oftentimes the correct terms can escape your mind when discussing code. Carefully planning a script allows you time to do the proper research to identify exactly what you want to say. You'll have the benefit of writing a script to match what you've already recorded on the screen. It's much easier to describe the action inside of a scene than it is to dream one up.
Do not write about things that aren't inside the code unless you are prepared to fill this space in with animations, diagrams, or more recordings. Let your code speak for itself. Your script should only give supporting details. Your script needs to answer "why" you're doing what you're doing on the screen. I've experimented with many different approaches to script writing. I've tried writing a script first and then coding second. This is not only more difficult, but its much less malleable. It's much easier to change words around than it is to change recorded code, by orders of magnitude.
When you're writing your script, you should be constantly moving back and forth through your recordings. Watch a sequence in full until its conclusion before starting to write. Try to get a feel for the pace of what's happening on the screen, and then write that rhythm into your script. Keeping a good pace is extremely difficult, it has to be managed well in every cycle - recording, writing, audio, and editing.
Read aloud what you're writing while playing through the code. This will help highlight timing or pace issues ahead of time. This will also help you remove words that may have sounded natural in writing, but do not sound natural in a normal speaking pace. You will want to limit editing as much as possible, and its always better to catch these issues ahead of time. Watch 5 minutes of video, write the script for those 5 minutes, then watch the 5 minutes again reading script aloud. Rinse and repeat with changes.
Writing a script is a moving target. Your code might change or get refactored, or things might change during editing. While your viewers will watch your screencast from start to finish, there could be days or weeks of difference between coding and writing the script for that piece of code. This gap is killer, it means you won't get a feel for the entire pace of the screencast. Factor this in and before you start writing sessions, read through and watch through everything up until this point. This will freshen you up with what's been previously discussed such as commonly used words and phrases.
Because of these pacing issues, it's good to write as much as possible in one sitting. Your screencast should be an assembly line process, which means you're wearing only one hat at a time. If you're in the writing mood, take advantage of this and write as much as possible. Doing so prevents you from having to play catch up with reviewing your code and script all over again.
The code you recorded and the words you speak make up 100% of your total content. Once they are recorded and released they are permanent. It's not like a blog where you can quickly make changes later and instantly update the content. Scripts are long, expect that. My script for Episode #7 was a little over 25,000 words - the size of a small novel. It took me about 25 hours to write it and edit it. So figure 1 hour per 1000 words.
If you start rambling about code or concepts or theory in the middle of your video you'll need to freeze the frame while you finish your thoughts. This will bore your audience. Unless you're prepared to jazz this up in post production - with cuts to Keynote animations, a sequence like pulling up documentation - try not to dive into too much detail outside of the code shown on screen. This will ensure you stay focused and deliver quick meaningful statements instead of large bloated ramblings.
Having solid audio is a mixture of style and recording technique. The first step is to have the right setup to record quality audio.
For me the hardest part about screencasting was recording audio. I couldn't get over how to deliver consistently, or make it sound like I wasn't reading from the script. This is because over the course of days or weeks I'd go in recording with the current mood I was in that day. Sometimes confident, sometimes with a lot of energy, sometimes late at night when I was exhausted. I struggled through the first 2 screencasts I did with recording and when I asked for a few developers to review them, the remarks I got were always negative.
Then one day I was watching The Colbert Show and realized something. Steven Colbert is successful because he plays a character on the screen - not his normal self. I realized this was the key to recording myself consistently. Imagine a character who pronounces or enunciates better than you do - one with more enthusiasm. Write out these characteristics. The next time you're recording, be that character, and speak like that character. Regardless of how you personally feel when you start recording, you'll be able to pick up where you left off.
Nothing will sound more unpolished or unprofessional than sounding like you're reading from a script. You've all heard it, whenever a child gives a book report, or someone gives a talk without looking up from their notes on the podium. It has this familiar anti-rhythm we can pick up on immediately. This is a skill you can learn to overcome. You might hear some people say to stop writing notes - which of course forces you not to read anything. But in screencasting, you're describing what's going on in the code, you have much less wiggle room, much less flexibility. And you've already invested in a script. Trying to remember everything is impossible. So you must read. So why does it sound funny when we read?
I believe this anti-rhythm is the result of focusing purely on a few words in front of you, instead of effectively weaving multiple words and sentences together. It's like the flashlight effect where you have no idea what's about to come up. You have no way to balance upcoming thoughts with the current moment. Think about how you communicate when you talk. While you're delivering what you're saying your mind is meanwhile ahead of it, formulating thoughts which will soon be delivered. Talking from a script requires this same process. You have to be aware of what's coming down the pipeline, you have to learn to read your words well ahead of time before they're delivered. Doing this allows you to make subtle changes in pitch, rhythm, enunciation, in a natural way, to balance and bring home your thoughts and ideas.
If you deviate from your script, you need to update the video to reflect what was said. If your script doesn't accurately reflect what's been recorded it will make it much more difficult to pick back up at a later time.
It's hard to record everything perfectly in one shot - don't expect to. But I recommend recording sentences flawlessly. Trying to splice together 2 takes of one sentence is far more difficult, takes longer, and there will be more artifacts than just recording the whole sentence again. In fact it could take 5 - 10 minutes to edit out mistakes, adjust audio levels, perfectly balance spaces for breathing, versus 5 - 10 seconds of recording the sentence over again. Just like with recording code, fixing mistakes later is more difficult, time consuming, and produces worse quality.
It's finally time to put everything together. Editing involves syncing your recorded video to your recorded audio. Be prepared for this to be painstakingly slow.
If you replace 5 minutes of talking with your face on camera with 5 minutes of anything else - diagrams, illustrations, animations, text, screenshots, showing the code in action, documentation, API's - you'll have a much better screencast. Nobody cares about you, they care about what you're saying and what they can learn from what you show on the screen.
I'm serious - edit out every single typo. Every fumbled keystroke is a useless frame, and wastes time. Remove them all. Nothing breaks audience flow and concentration faster than typos. This goes back to recording - if you prepared well then you've made your job in editing tremendously easier. If you didn't, then you will burn immense amounts of time fixing all the mistakes now.
The worst possible thing you can do in a screencast is waste the audience's time by debugging on camera. Showing errors is perfectly okay though - these are not the same thing. It's perfectly acceptable to prime and prepare the audience for going down a path that causes an error. The difference is you, the director are preparing the code in such a way that demonstrates a problem and then you correct the code.
Nothing could be stronger than being in control of errors, explaining why they happens, and how to get around them. This is however completely different than debugging "live" where you are unsure of the problem while on camera. Highlight errors effectively, don't show typos and syntax problems, and never debug.
There will be some people that say they "like" the "real" feel of debugging. What they're really saying is "I like watching experienced developers be presented with a problem, think through this problem, and solve it". You can still provide this 100% without doing any "live" debugging, which will trim and reduce the fatty parts of a screencast down to the lean essentials. You'll still be providing high quality material, giving the audience a true insight into problem solving, without wasting a lot of time.
Editing offers you the ability to enhance your arguments, showcase and highlight your code, and provide supporting documentations and illustrations. You should be accelerating the frame rate during boring parts of code writing - usually to 150% or 200%. The audience can read what you're typing much faster than you can type it. If there's silence while your code is being typed, that's a sign you need to speed up the frames.
On the contrary you'll also be freeze framing on a regular basis. You'll use this to help explain a concept with the code to match up to your audio. You might type a few methods, which takes only 2 seconds but requires a 10 second audio explanation. You'll freeze frame for 8 seconds.
Be wary of not doing this too much or too long. If there's an in depth explanation - cut to some documentation supporting your argument, or highlight your code with a callout or arrow illustration. Show the audience how you know your code does what it does. Show them how you approach finding the answer. Do you google it? Do you jump to some bookmark? This is a super valuable skill your audience will identify with and certainly appreciate. It will also force you to be very confident in what you're saying.
There is a pace and a rhythm when your code and your audio is in sync. It takes time to develop this, but eventually you'll get a feel for how much empty space there should be between breaths - between phrases and thoughts. How much lead in you should give with what's going on screen vs what you're saying is happening. Generally I like to explain what's going on slightly faster than it really is. Such as --
okay we're going to write this method in such a way that allows us to... meanwhile the code is just starting to actually write the method. This gives the audience the mental ability to digest your words and their code expectations follow right behind. This way they see where you're going slightly before you get there.
If you're using a sensitive microphone, your audio with consist of a lot of weird breathing, clicking, slurping, swallowing noises you'd never normally hear. I find these highly distracting, and their presence indicates poor editing. They're a huge pain to remove manually, but solid video editing software can help automate this.
The majority of the work in screencasting is done in your video editing software. Take it as seriously as you take your code editor. Watch tutorials on how to use it, know all of the shortcuts. When I first started in Screenflow, and even Keynote on Lynda watching an 8 1/2 hour tutorial. I've since moved beyond Screenflow, and I've watched day-long tutorials in both Adobe Premier Pro and Final Cut Pro.
Editing is the longest, most tedious process. At my fastest speeds I can edit about 5-10 minutes of video every hour. If I'm doing Keynote animations it ends up taking about twice as long. This is in a best case scenario though. I've spent an entire day on a 5 minute sequence that had all kinds of continuity issues. I've wasted a lot of time editing audio that could have just been re-recorded. Anything that just doesn't "fit" perfectly needs to be re-recorded. You'll increase quality dramatically and end up saving a lot of time. Don't cut corners. I have at least one edit on average every 2-3 seconds. Episode #7 had thousands of edits.
There is nothing more devastating to the creative process than stopping midway through screencast production. Getting back into it wastes hours - if not days. Having a well documented outline, script, annotated recordings and notes makes this possible. Without these it would be almost like starting over. You will not remember why you recorded X sequence of code, you will not remember that you wanted to insert Y animation at Z point in time. You will forget what you said in earlier parts of the episode, you will repeat yourself, use the same phrase too many times, or even flat out contradict yourself. In a really long episode this is something you have to deal with even without taking any breaks. Episode #7 took me a month to finish, and by week 3 and 4 I had lost that touch and feel of what I covered in weeks 1 and 2. The bigger lesson is not to bite off too much. Smaller episodes are more favorable to epically long ones.
I've felt like quitting on each and every episode I've worked on, without a doubt. I've recorded an hour of audio on the wrong microphone and didn't realize it until much later. I've had my video editor crash on me losing hours of work. Disasters will happen, and they'll make you want to quit. Longs nights of editing become exhausting.
But don't give up! You'll get faster and better as you learn more about screencasting. Finishing an episode is an incredible accomplishment and highly rewarding. It's impactful to your skillset, and even your career. Nothing speaks better towards your capabilities than demonstrating proficiency and communicating on the screen. Good luck on your screencasting endeavors!Tweet