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.
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.
720p is the target resolution. In pixel terms this is 1280x720. We've gotten the best 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.
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 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.
There are a number of great tools for this. Screenflow and Camtasia are both excellent, depending on how you like to work. I've found that Screenflow is lighter, and more "Mac". YMMV
It is really nice (ok, essential!) to do a touch of light editing, especially to "fill in" long bits of typing, or jump through computer processing time (think npm install) because nobody wants to watch that on video.
Otherwise, it is up to you. I like to record my audio first, and edit it over the video. Some people are the "one take dazzle" and just get it done.
We've had a lot of success by recording in "chunks" and doing a bit of minimal editing to get the best take.
The ultimate goal is to be as conversational as possible. You're sitting down with a friend or colleague and showing them something cool, or teaching them a new concept.
You definitely don't want to come off like you are reading from a script. I do use a script, just because it helps me, but if you do this a bit you'll notice that you write a lot more formally than you speak in conversation. Your script should reflect that, and it will be a lot easier. I use them as a guide, and will do a read through or two out loud to load it into my brain and get a more casual result.
Here's my gear list.
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.
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.
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.
They almost always want code, even for the most trivial things.
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.
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!
If you want to read a bit more, this series is great, and digs a little deeper into some of the specifics.
We're always looking for passionate contributors, and would love to talk to you. Record an "egghead style" bite-sized "pilot" and send the link to firstname.lastname@example.org!