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 2560x1440 in a HiDPI (pixel double) 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 like 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 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 developmenr?
- 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.
- 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.
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.