Recording a Great Coding Screencast

#screencast #tutorial #tips #guide

It seems trivial to record a 1-8 minute screencast, but there are actually quite a few moving parts when it comes to recording a high quality screencast. Here's some of our thoughts on the subject.

If you're interested in a more in-depth guide to how we create lessons for egghead.io, please check out our instructor's guide.

The Screen

First and foremost a coding screencast is about the code, and we need to make sure it looks great. There are a few aspects to this that help ensure that is the case.

Resolution

1080p is a great target resolution, but we've also had great results when we record at 1280x720(HiDPI) mode, giving an effective visible resolution of 1280x720, but extremely crisp. This resolution is achievable on 27" monitors and retina MBPs.

To enable HiDPI, we use the RDM tool. On retina MacBooks, this "just works". For external monitors, or non-retina Macs, you can follow these instructions to enable HiDPI mode.

Using HiDPI mode gives an extremely crisp final product that looks fantastic (readable) on phones and tablets.

If you can't use this mode, recording at normal 1280x720 is a decent substitute. By constraining to this small window, you are able to fill the screen effectively for coding screencasts.

The Code

The code is the champion of the screencast. To that end, it deserves maximum horizontal space. It is a good idea to use an 80 or 120 character "column" for the code and bump the font size up to fit.

We will typically work in a 3 column layout, with the editor taking up 2/3s and a browser on the right side in the remaining 1/3 of the screen. You might prefer to flip back and forth between the browser and the editor, it is up to you.

It is important to keep in mind that some padding allowances should be considered for the top and bottom of the recording window, as they can get cut off by player chrome.

Recording

We strongly encourage recording in small "takes" rather than trying to record the entire lesson. A take can be as small as a single sentence. Try each take as many times as you need. When you make a mistake, just undo your last sentence and try again. Recording in tiny takes sets you up for success when it comes time to edit.

When it comes to time to actually record your screen, my personal preference is Screenflow. Recording is simple and the editing experience is smooth. But there are plenty of other great options out there.

Editing

Now it's time to cut out all the mistakes. If you followed the "take" advice, you can reach for the "ripple delete" tool and easily chop out all of the mistakes you made. I strongly recommend editing your lesson immediately after you record so all the mistakes you made are fresh in your mind.

The more confident and practice you get with editing, the more confident you will be with making mistakes in your videos. So it's a good idea to try out the whole process a few times when you're just getting started to get the hang of working in a "takes" mindset.

What Should I Say?

Your words should reflect what's happening on the screen. Don't talk without showing something and don't show something without talking. As you walk through the steps of your lesson, you can keep the user focused with the forward progress you're making. So the more you give instructions like "type this" or "click that", the more the user has to pay attention.

Volume

Volume is important. Nothing ruins an awesome screencast quicker than messed up levels. I use a small laptop and headphones to test my audio. On the laptop, I want the volume to be clear from across a small room, with minimal distortion. It should be in stereo and sound good in headphones too. With headphones, max volume should be loud, but distortion free.

Content

This is totally up to you.

What are you stoked about in web development?
What do you see as being painful, and how do you solve it?

Our basic guideline is to identify pain. A Pain Thesis™, if you will. Identify the pain, state it, and then walk through the solution. There is so much pain in web development, and this provides endless quantities of worthy topics.

Feel free to scour Stack Overflow for questions and create videos that answer them. Video offers an advantage over a simple copy/pasted code example because you can show the process. Developers love watching process! (And feel free to amaze them with your custom workflows)

Have fun! Convey the joy you've found in solving software problems and sharing those solutions with others. We're not professors shoving text books down students throats. We're not trying to fill some sort of quota or meet deadlines. We're doing this because we love sharing information and care deeply about code and best practices.

Supplemental content

People are very keen on getting their hands on the code. There are a couple approaches to this.

Full-on Project: This is how you would normally work. Structured, full project that makes use of dependency management systems and requires a brief README to explain how to get running ASAP.
Minimal Files: An HTML file and a JavaScript file. In this case, use CDN links where possible.

They almost always want code, even for the most trivial things.

Stay Focused

If you need to go off on a tangent, consider making another separate video. Your audience is watching your video for what you put in the title, so do your best to limit to that specific topic. This also has the side-benefit of making the video easier to find and organize in groups with other videos.

We make "bite-sized" videos because our audience's time is precious. Each video should have enough content to satisfy a learning craving while also supporting binge-watching across multiple videos for those developers diving head-first into the latest and greatest technologies.

Top 10 egghead screencasting tips

Stick to it. It's worth it. - This is work. You're new to this. Expect it to be hard, but expect to succeed when you put in effort. The final payoff is huge.
Accept feedback gracefully.
Relax and have fun. - Humans are more trustworthy than robots. Monotone voices kill lessons. This stuff is interesting, so let it come across in your lessons that you are truly interested.
Do Dry Runs - Just hit record and start talking. Create a terrible lesson. You'll learn a ton by just doing it live. Then, do it again. You'll nail it down in a few takes and it's much easier than just sitting there stressing about it.
FOCUS - Write your lesson title. Teach only about that title. Don't go off on tangents, instead, MAKE MORE LESSONS!
Show, the flow - Every example has a "stream" of how pieces fit together. It will be obvious to you and you'll be tempted to skip over it because you think it's too obvious. Show how the code goes from point A to point B. Show how task X outputs file Y. Show how button M makes div N disappear.
Make A LOT of mistakes, then edit - This is NOT a conference presentation. You do NOT have to be "perfect" or "practiced". You just need to edit out the mistakes. So relax, say stupid stuff, pause, do it again, then edit out the bad stuff later. LOTS of pausing. LOTS of mistakes. Editing is easy.
End fast, start faster - Avoid saying "Hi". Skip "This lesson is about X, Y, Z" Just go. They can read the title of the lesson above the video. Then at the end, just stop. Don't say "Next time", just MAKE THE NEXT LESSON!
Recap when it's complicated - If your lesson has a lot of moving pieces, use the end to walk them through all the steps again. Basically show the flow part 2.
Be tidy - If a section gets "sloppy", stop yourself and start over. Having to watch a lesson where an instructor "reacts" the lesson is painful. Take control of the lesson and stay in control. You are the authority.

Conclusion

It takes a little practice, and it can be surprising how long it takes to record a condensed 3 minutes of excellent coding how-to. It definitely gets easier with practice!