How to record screencasts
Because I have a long time record screencasts for Ruby and do it regularly, think I'll be able to share a few tips on how to make your screencasts watchable and useful. I have here, of course, a vested interest — I wish more people realized the strength to produce quality educational material and began to put it on the network, including we hasBrains.
1. Select a quite extensive topic that you understand well.
I think you don't need to be super-professional, but of course need confidence in their knowledge and desire to understand what you still not understand. In the process of recording screencasts, I sometimes looked in the documentation and sometimes find something new. It's a process. One of the reasons I started to teach other people and to record screencasts is to become smarter than myself.
2. Choose the correct words and terms.
A lot of attention screencast I pay to use the correct words and terms. People often underestimate the meaning of specialized vocabulary is a mistake. There is a big difference between a "class method" and "instance method". Continuous use of the correct vocabulary not only helps the audience ability to communicate with the author of screencasts and other people, but also serves as a constant reminder: if 10 times to repeat the term that the person does not understand, sooner or later, he zadolbali and will take the time to review the screencast, which explains its meaning. Or simpler — you will find the term in Google. a desire for students: pay particular attention to the terms — only by understanding the terms you can really understand the subject.
3. Choose to release screencast one narrow theme and show it on the example.
Release screencast should provide a complete unit of knowledge, so to speak. I think a good screencast contains: a) topic title b) a task that will be implemented, through the study of this topic. It seems to be obvious, but it is difficult to observe this rule. I only noticed it later when the topic started to become harder and each topic required more code. Even more difficult to comply with this rule if you show something on the sample and if this sample grew over a few releases (as happens in my screencast where we store working from the terminal). Usually I make up in my head (and sometimes on paper) plan screencast to when I pressed the button "Start Rec" I knew what and how I want to show.
4. Always put yourself in the shoes of the viewer.
It is very important to keep in mind that the audience already knows from your previous screencasts, and what is not; that he might forget and that could learn well enough. And, of course, to use the terms and knowledge that are not yet available audience. It is very important to think about how to hold the viewer's attention. Remember, the screencast — not a lecture at the University, to the viewer at any time can become boring and he can go watch funny fluffy namecheck on YouTube. To hold the viewer's attention — screencast should be a clear objective (see paragraph 3), which will be achieved by the end of the episode.
5. Control the breathing and avoid words-parasites.
It is very difficult to speak so that people liked to listen to you. This becomes clear as soon as you begin to hear your voice in the recording. Before you heard his voice in the recording, it probably never came up. I always listen to myself in recordings and I hate how I talk. It helps to become better. If you are a professional in your field and your every word is like gold, but you cannot hear — will be of little avail. So even if you don't 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 nice to listen to you. And of course, almost the most obvious and important point in improving your speech — to remove from it "um" and "uh". Make the effort and watch it.
6. Not literally describe what is happening on the screen.
It should complement the visuals, not to describe the obvious. For example, if I write this code
I'm not going to say "and now I write the word def, then the word quack, which is the method name, then open parenthesis and in brackets write the name of the message variable". No, it's literal and pointless retelling of the screen. I say "I will now announce the quack method that takes a single argument containing the output in the terminal greeting our ducks."
7. Select the normal software to record.
I use Camtasia. Features that I like: the ability to pause at any time with a keyboard shortcut, a convenient editor with a minimal set of necessary features (cut out, glue two pieces).
Here, it is perhaps that set of tips, which was formed in my head right now. I myself have not always followed all of these tips. So I guess this post is as much for me as for everyone else — a reminder of what to strive for.
***
Take a moment to remind you: we are looking for people who want to record screencasts on hasBrains — when the link to the left marked in gray, it is quite possible that we're looking for a author for that section. In this case, please contact us, if you feel the strength to burn materials. I personally would be very interesting to collect hasBrains talented and smart people willing to share knowledge — it seems to me that the network is now missing.
Article based on information from habrahabr.ru
1. Select a quite extensive topic that you understand well.
I think you don't need to be super-professional, but of course need confidence in their knowledge and desire to understand what you still not understand. In the process of recording screencasts, I sometimes looked in the documentation and sometimes find something new. It's a process. One of the reasons I started to teach other people and to record screencasts is to become smarter than myself.
2. Choose the correct words and terms.
A lot of attention screencast I pay to use the correct words and terms. People often underestimate the meaning of specialized vocabulary is a mistake. There is a big difference between a "class method" and "instance method". Continuous use of the correct vocabulary not only helps the audience ability to communicate with the author of screencasts and other people, but also serves as a constant reminder: if 10 times to repeat the term that the person does not understand, sooner or later, he zadolbali and will take the time to review the screencast, which explains its meaning. Or simpler — you will find the term in Google. a desire for students: pay particular attention to the terms — only by understanding the terms you can really understand the subject.
3. Choose to release screencast one narrow theme and show it on the example.
Release screencast should provide a complete unit of knowledge, so to speak. I think a good screencast contains: a) topic title b) a task that will be implemented, through the study of this topic. It seems to be obvious, but it is difficult to observe this rule. I only noticed it later when the topic started to become harder and each topic required more code. Even more difficult to comply with this rule if you show something on the sample and if this sample grew over a few releases (as happens in my screencast where we store working from the terminal). Usually I make up in my head (and sometimes on paper) plan screencast to when I pressed the button "Start Rec" I knew what and how I want to show.
4. Always put yourself in the shoes of the viewer.
It is very important to keep in mind that the audience already knows from your previous screencasts, and what is not; that he might forget and that could learn well enough. And, of course, to use the terms and knowledge that are not yet available audience. It is very important to think about how to hold the viewer's attention. Remember, the screencast — not a lecture at the University, to the viewer at any time can become boring and he can go watch funny fluffy namecheck on YouTube. To hold the viewer's attention — screencast should be a clear objective (see paragraph 3), which will be achieved by the end of the episode.
5. Control the breathing and avoid words-parasites.
It is very difficult to speak so that people liked to listen to you. This becomes clear as soon as you begin to hear your voice in the recording. Before you heard his voice in the recording, it probably never came up. I always listen to myself in recordings and I hate how I talk. It helps to become better. If you are a professional in your field and your every word is like gold, but you cannot hear — will be of little avail. So even if you don't 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 nice to listen to you. And of course, almost the most obvious and important point in improving your speech — to remove from it "um" and "uh". Make the effort and watch it.
6. Not literally describe what is happening on the screen.
It should complement the visuals, not to describe the obvious. For example, if I write this code
def quack(message)
puts "duck says #{message}"
endI'm not going to say "and now I write the word def, then the word quack, which is the method name, then open parenthesis and in brackets write the name of the message variable". No, it's literal and pointless retelling of the screen. I say "I will now announce the quack method that takes a single argument containing the output in the terminal greeting our ducks."
7. Select the normal software to record.
I use Camtasia. Features that I like: the ability to pause at any time with a keyboard shortcut, a convenient editor with a minimal set of necessary features (cut out, glue two pieces).
Here, it is perhaps that set of tips, which was formed in my head right now. I myself have not always followed all of these tips. So I guess this post is as much for me as for everyone else — a reminder of what to strive for.
***
Take a moment to remind you: we are looking for people who want to record screencasts on hasBrains — when the link to the left marked in gray, it is quite possible that we're looking for a author for that section. In this case, please contact us, if you feel the strength to burn materials. I personally would be very interesting to collect hasBrains talented and smart people willing to share knowledge — it seems to me that the network is now missing.
Comments
Post a Comment