I like people who put up how-to videos on YouTube showing how to do things they enjoy doing, particularly videos about gaming, game design, development, programming, art, criticism, reviews, you name it. But, unfortunately the majority of them are not as well produced as they should be.
The equipment to make videos is cheap, readily available, and increasingly easy to use, but making a good video is still not a simple thing. High quality production values and good content is requires work, but time and again I see a lot of the same amateurish mistakes made, and a lot of them are easy to correct.
Set up
- Test your recording and capture setup. Test your setup! Test your setup!
- Do a quick sample take, and quality-check your results. If there’s a problem with the quality, bite the bullet and re-do the video. But avoid wasting that time by verifying the setup is right before you start production.
- Check your audio levels before recording. I can’t tell you how many videos I can’t hear on my laptop’s speakers. But I have no problem at all hearing audio on my laptop when the recording levels were good.
- Make sure that the audio track is audible, that there is no background noise, buzzing, dogs, traffic, airplanes, or anything else that distracts from the audio. Clear and sharp is nice to listen to.
- Test your video capture quality. If you’re dropping frames, or getting blurry results, figure out why, and fix it before you post a video. Trying to read code through low-resolution downsampling or mpeg artifacting is awful.
Content
- Know what you’re talking about. Take the time to really learn your subject before you go out and publish videos. You don’t need to know it inside and out, but do know the topic you’re going to cover.
- Think about what you’re going to say before you say it. Write up an outline or cue cards or a script if you need to. Have an agenda and don’t stray too far from it.
- Get right to the point.
- It’s fine to re-record the audio track and narrate over the video — it’s really hard to talk and do something that requires skill or thought at the same time. If you’re doing a programming tutorial, much of the video will probably be a still image of the screen, which you can pause and talk over as long as you need to.
- Practice and rehearse. Don’t subject your audience to you fumbling about with your words or with the tools. There’s nothing wrong with stopping and doing it over, or at least editing out the mistakes. It’s harder than it looks. If you make a mistake, just keep going back and try again until you get it right, and then edit out the mistakes.
- Speak naturally, but clearly and out loud, like you’re talking to a room full of people, rather than mumbling like you’re trying to avoid waking up someone sleeping in the next room. Try to project some vitality and excitement.
- Have an intro. Get it out of the way quickly, but have it. Tell people who you are, where people can go to find out more about you and your projects, and what you’re topic you’re going to be talking about today. Say it out loud, put it in print on the screen, and put it in the video description.
- Video footage of the working project being demonstrated. Show off all the features. This is the part of the video that will get attention and draw people in.
- Now go under the hood. Now that you’ve shown us what your demo can do, take us on a tour of the code and explain how it works. This is the really interesting part of the video.
- Iterations. If you build up the project in iterative phases, show that process. It’s very helpful to show new programmers how to break down a problem into smaller parts, and put those parts together and refine the approach toward a well-polished solution. Show the project in its stages of development, but don’t force us to watch the entire process start to finish. Skip to the good parts.
- If it’s interesting, talk about alternative approaches, their pros and cons, and why you chose to do things the way you did. Was performance critical here? Flexibility of the solution? Code maintainability? Modular design? If there’s controversy over one approach vs. another, do a side by side demo of each approach, comparing their strengths and weaknesses.
- Think about ways to say what you’re saying more simply. Don’t think on camera. You’re supposed to be presenting what you know, not discovering it.
Postproduction
- Edit! If you are rambling, or misspeak, go back and edit it out, or do a re-take.
- Some people like to appear on camera. Nothing wrong with that. But when it’s time to show what’s on screen, switch to video capture software as your input source. Don’t film the screen over your shoulder. Use your editing software to stitch the shots together. You don’t have to do it all in one take.
- Subtitles are appreciated, but if at all possible, don’t do “poor man’s subtitles” by opening up a text editor, setting the font big, and typing what you’re doing. Especially, don’t use this as the only method of conveying what you’re doing, in lieu of voice narration. Watching you type in realtime is extremely boring, especially if you hit backspace a lot.
- Unless the video is on the topic of how to use the IDE, try to shorten or eliminate the amount of time devoted to navigating the interface. Most people know how to create a new asset, drag-and-drop a command into the Actions pane of the object editor, or type a file already. What’s interesting is what you’re putting in the asset. If you want to walk people through some code, that’s great, just don’t make us watch you type it. Paste it in, and then go through it line by line, highlighting the line you’re talking about if necessary. Instead of building the project up in front of the camera, walk people through a pre-built project, explaining it in detail.
- Make your code style as presentable and readable as possible. Your code should be beautifully formatted with a extra attention paid to readability. Use well-chosen names for assets and variables. Use whitespace and indenting. Don’t code slop with the excuse that you’re doing things quickly because you’re on video. We’re watching the video in order to see how well you can code.
- Don’t put a musical soundtrack in your video, or any other sort of filler audio. Narrate. Intro/outro music is fine if you’re shooting for professional polish, but not necessary. If you do use music, make sure a) it doesn’t suck, and b) it doesn’t get your video pulled for violating someone else’s copyright.
- Ask yourself: Does the video need this? Cut extraneous bits. If you need to fiddle with your mic, or answer the phone, or whatever, cut it.
- Ask yourself: Could I have done it even better? Re-do it.
- Don’t post junk. If it didn’t turn out well, you don’t have to post it.
- Don’t shoot for absolute perfection. A few minor flaws are excusable. But do try to make the best quality videos that you can.
Essential extras
- Host a demo project file somewhere, and link to it from the video description. If you’re sharing your knowledge and techniques, you might as well share your code. You’re already sharing it through the video, but by not including the downloadable project, you’re forcing everyone to waste their time re-typing in your code. There’s really no reason not to just provide it. There are many options for free file hosting services: google drive, dropbox, mediafire, github, sourceforge, the list goes on.