Insights of a new screencaster

I recently created a series of screencasts for students having to resit an exam after six months of not having any contact with the subject. I wrote about these videos in another post.

While this was not my first experience teaching programming, my previous times had always been in person. This experiment was my first time planning, recording and publishing screencasts, during which I learned a few basic rules on what to do and what to avoid.

Shorter videos are easier to make

Initially, I had the urge to tell viewers everything there is to know about a specific topic in one go. This made my notes unnecessarily long and less helpful, resulting in me occasionally losing track of what I wanted to talk about next.

Cutting down the length of your videos to around five to ten minutes requires you to focus on one thing and explain it really well. Not having to rush to the next topic allows you to go into as much or as little detail as you want without the viewer being turned off by an unnecessarily long video.

This also makes it easier to prepare for the recording. I usually talk through the entire content once or twice before recording, which is much less effort if there is less to say.

Recording short videos again is quick

My screen recording application of choice, ScreenFlow, sometimes refused to display the content I had just recorded. On these rare occasions, I completely lost what I had produced.

Luckily, this only happened on very short videos that were easy to record again. While certainly annoying, it was not nearly as horrible as losing several hours of content would have been.

ScreenFlow-Protip: always create a “New Empty Document…” before starting your recording. I did not lose a minute of content once I started doing that.

Shorter videos are more user-friendly

From a viewer’s perspective, overly long screencasts can feel intimidating and much harder to tackle than ones that are only a few minutes long. Short videos are easier to fit into their potentially busy schedules, thus increasing the probability of the videos actually getting watched.

They also make it easier for viewers to go back and refresh their memory of a specific subject without having to search for the few parts currently relevant to them.

Feedback is hard to get

Even though I recorded the videos for people in my degree course that often knew me personally, getting feedback was difficult. My questions on what else they would want me to explain did not yield a single answer.

However, the rare feedback I got was incredibly helpful and is present throughout this post. Apart from these instances, the only real feedback I got was through the analytics provided to me by YouTube, which revealed a few interesting aspects:

• the videos were actually getting watched
• viewers who made it past the first few minutes of a video usually finished it
• about 30% of viewers watched videos from beginning to end
• shorter videos had an audience retention of closer to 50%
• view counts rapidly declined on later, more advanced topics
• the introductory video remained the most popular one until the end

While not overly helpful, my assumptions are that people expect you to know what they should be taught and that, as noted above, shorter videos are in fact slightly more popular.

High-quality audio is important

Since this was my first attempt, I did not yet buy an external microphone and only used the built-in one of my MacBook Air (Mid 2012). While it was decent enough, some viewers pointed out that the volume on my videos ended up being too low.

In the long run, you are going to need a high-quality external microphone. The Blue Snowball is frequently used in podcasting and seems to be a good choice to start out with. At a higher price point, the Heil PR 40 is also receiving good reviews from professional broadcasters.

Until then, you should try to normalize the audio and remove background noise if possible, something applications like ScreenFlow are usually capable of.

Type less, talk more

Talking while simultaneously writing code was very unfamiliar to me, yet not as hard as I expected it to be. Still, long examples would occasionally trip me up and result in longer silences.

Ideally, you want to be able to talk fluently while only using code to back up what you are saying. This is similar to how one should not put vital content on slides when giving a presentation: the important content should be in what is being said, not what the viewer can see.

Not only do simpler examples allow you to do that, they are also going to be easier to understand.

YouTube’s content detection is weird

This one is more a curiosity than something I intend to do anything about: on two separate occasions, YouTube automatically flagged my content as “including third-party content”. Containing nothing but my voice over a video of me coding, this was obviously wrong.

My uploads fortunately remained available, but I had to refute the claims through YouTube’s interface, which only takes a few minutes. Both claims got withdrawn, but these instances were slightly annoying because they forced me to take unnecessary actions.

Screencasts are fun

Testing the waters in this medium was a great exercise. The amazing thing about screencasts to me is that they are easily accessible and often remain relevant for years. The lecture that inspired me to do this experiment happens regularly, so my videos could undoubtedly be of use to future semesters.

I fully intend to retake these episodes, keeping what I learned during the first run in mind. Screencasts are definitely something I can see myself doing more of in the future.