How to record screencasts

Since I have been recording Ruby screencasts for a long time and doing it regularly, I think I can share a few tips on how to make your screencasts watchable and useful. I have here, of course, a vested interest - I want more people to realize the strength to produce high-quality educational material and begin to post it online, including in our hasBrains .

1. Choose a fairly extensive topic that you understand well.
I think you do not need to be a super professional, but, of course, you need confidence in your knowledge and a desire to understand what you don’t understand. In the process of recording screencasts, I sometimes glance at the documentation and, sometimes, I find something new for myself. This is a process. One of the reasons why I started teaching other people and recording screencasts is to become smarter myself.

2. Choose the right words and terms.
I pay great attention to screencasts to use the right words and terms. People often underestimate the meaning of special vocabulary - this is a mistake. There is a big difference between the "class method" and the "instance method". Constant use of correct vocabulary not only helps the audience communicate more effectively with screencast author and other people, but also serves as a constant reminder: if you repeat a term 10 times that a person does not understand, sooner or later he will get tired and find time to revise the screencast where its meaning is explained. Or easier - find the term in Google. A small wish for the students: pay special attention to the terms - only by understanding the terms you can really understand the subject.
')
3. Choose a single topic for screencast release and show it with an example.
The release of the screencast should be a complete unit of knowledge, so to speak. I think a good screencast contains: a) the name of the topic b) the task that will be implemented by studying this topic . It seems to be obvious, but it can be difficult to follow this rule. I noticed this only later, when the topics started to get more complicated and each topic required more code. It is even more difficult to follow this rule if you show something with an example and if this example has grown over several issues (as it happens in my screencasts where we make a store working from the terminal). Usually I draw up a screencast plan in my head (and sometimes on paper), so that when I press the Start Rec button I know what and how I want to show it.

4. Always put yourself in the place of the viewer.
It is very important to keep in mind that the viewer already knows from your previous screencasts and what does not; that he can forget, and that he could learn well enough. And, of course, do not use the terms and knowledge that are not yet available to the audience. It is also very important to think about how to keep the viewer's attention. Remember, a screencast is not a lecture at the university, the viewer can get bored at any time and he can go and watch funny fluffy yyamochek on Youtube. To keep the viewer's attention, the screencast must have a clear goal (see point 3), which will be achieved by the end of the episode.

5. Control your breathing, avoid the words of parasites.
It is very difficult to speak so that people like to listen to you. This becomes clear as soon as you begin to hear your voice in the recording. Before you heard your voice in the recording, you probably didn’t even think about it. I constantly listen to myself in recordings and hate the way I speak. It helps to become better. If you are a professional in your field and your every word is worth its weight in gold, but it is impossible to listen to you, there will be little confusion. So even if you do not record screencasts, try to pay attention to how you talk - I think this skill is useful in life in general. I repeat: people should be pleased to hear from you. And of course, almost the most obvious and important point in improving your speech is to remove “eeee” and “mmmm” from it. Make an effort and watch this.

6. Do not describe literally what is happening on the screen.
Speech should complement the video series, and not describe the obvious. For example, if I write such code

def quack(message)
puts "duck says #{message}"
end

I will not say "but now I write the word def, then the word quack, which is the name of the method, then I open the parentheses and write the name of the message variable in parentheses." No, this is a literal and meaningless retelling of the screen. I will say "and now I will declare the quack method, which takes one argument containing the greeting of our duck to the terminal."

7. Select the normal software for recording.
I use Camtasia . Features that I like: the ability to pause at any time with a shortcut key, a handy editor with a minimal set of necessary features (cut a fragment, glue two pieces together).

Here, this is probably the set of tips that has formed in my head now. I myself do not always follow all these tips. So, probably, this post is just as much for me as for all the others — a reminder of what to strive for.

***

I will take a moment to remind you: we are waiting for people who want to record screencasts on hasBrains - when the link to the section on the left is gray, it is quite possible that we are looking for the author for this section. In this case - write to us if you feel the strength to write materials. I personally would be very interested in gathering talented and smart people ready to share knowledge on hasBrains - I think this is not enough for the network right now.