How to record screencasts

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

    1. Choose a broad enough 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 still do not 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 I started teaching other people and recording screencasts was to become smarter myself.

    2. Choose the right words and terms.
    In screencasts, I pay a lot of attention to using 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". The constant use of the right vocabulary not only helps the audience communicate more effectively with the author of the screencasts and other people, but also serves as a constant reminder: if you repeat a term that a person doesn’t understand 10 times, sooner or later he will get sick and find time to review the screencast where its meaning is explained. Or simply - find the term in Google. A small wish for students: pay special attention to terms - only by understanding the terms can you really understand the subject.

    3. Choose one narrow topic for the screencast release and show it as an example.
    Screencast release 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 comply with this rule. I noticed this only later when the topics started to get harder and each topic required more code. It’s even more difficult to follow this rule if you show something using an example and if this example has grown over several issues (as happens in my screencasts, where we make a store that works from the terminal). Usually I draw up a screencast plan in my head (and sometimes on paper) so that when I click the “Start Rec” button I know what and how I want to show.

    4. Always put yourself in the shoes of the viewer.
    It is very important to constantly keep in mind what the viewer already knows from your previous screencasts and what not; what he can forget, and what he could already learn well enough. And, of course, do not use terms and knowledge that are not yet available to the audience. It is still 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 become bored at any moment and he can go watch funny fluffy namyamochki on YouTube. To keep the viewer's attention, the screencast must have a clearly set goal (see point 3), which will be achieved by the end of the episode.

    5. Control your breathing, avoid the words of the parasites.
    It is very difficult to say so that people enjoy listening 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, it probably never occurred to you. I constantly listen to myself on the tape and hate the way I speak. It helps to get better. If you are a professional in your field and your every word is worth its weight in gold, but you can’t be listened to, it will be of little use. So even if you do not record screencasts, try to pay attention to how you talk - it seems to me that this skill is useful in life as a whole. I repeat once again: people should be pleased to listen to 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 keep an eye on it.

    6. Do not describe what is happening literally on the screen.
    Speech should complement the video, and not describe the obvious. For example, if I write such code I won’t say “now I write the word def, then the word quack, which is the name of the method, then I open the brackets and write the name of the variable message in brackets”. No, this is a literal and meaningless retelling of the screen. I’ll say, “Now I’ll declare a quack method that takes one argument containing the terminal’s greeting to our duck.” 7. Select the normal software for recording. I am using Camtasia . Features that I like: the ability to pause at any time with a keyboard shortcut, a convenient editor with a minimum set of necessary features (cut a fragment, glue two fragments).

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







    Now, 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 as much for me as for everyone else - 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 grayed out, it is quite possible that we are looking for an author for this section. In this case, write to us if you feel in yourself the strength to record materials. I personally would be extremely interested in collecting talented and intelligent people on hasBrains who are ready to share knowledge - it seems to me that this is not enough on the network right now.

    Also popular now: