Screencasting Like a Pro: The Demos

Hopefully, You've Mused

The first two posts of mine on this subject dealt with creating an outline and then executing the basics of a script. This is, more or less, supposed to be a thought exercise on your part - focusing you on what it is you're trying to say and whether it's worth it for them to hear it.

I've already received feedback from people along the lines of

Love the tips! Maybe if I want to sell my screencasts someday I can use your tips in full!

I know that it's hard to do what I'm suggesting here. I know it takes time - believe me... I know. If you're thinking along these lines (that a paywall will dictate the quality of your content) - please consider:

• Ryan Bates has issued over 300 screencasts of enormous quality, only erecting the paywall in the last few months. And it's well worth it.

• Your voice, your code, and (basically) you are recorded for all to see, for years to come. For personal and professional reasons I might suggest giving it everything you've got.

• The less you give, the more no one will care.

I wanted to start off with this because it's only going to get harder from here. Not in terms of tools, vocal work, or clever words. It's going to get harder because the polish is created up front - not afterward.

Let's go.

Care. Give it.

We have a script and we need to underscore our point with demos. These demos should revolve a singular truth:

Shut up and show me the code

Given that, let's consider what makes a good demo:

1. The viewer knows what they are about to see as you've told them
2. The viewer sees the code that makes your point
3. The viewer is left with something to think about and may, or may not, agree with you

We need to focus on a beginning, middle, and end to all of our demos. We can't spend time on tangents, and we can't take time out to preach. This is yet another thing I learned from Scott Hanselman.

I have a decent number of "bad" demos on very popular sites that I like to point to as "what not to do" - but I want to keep this positive and drive home the point I'm trying to make: Stay On Target.

Consider these options when explaining Dependency Injection:

Dependency Injection is a software pattern that many seasoned developers use for typed languages, and from that they've decided to use Inversion of Control Containers because it makes things a lot easier. Just take my word for it guys... it does. If you haven't used one yet you really should because it makes your life simpler and you'll stop writing crappy code that no one can debug. This one time...

Take two:

Dependency Injection is a software pattern that helps you write smaller classes that can do more, and also keeps you from writing code that can, like yarn, turn into a messy ball in the future. The idea is that you send dependencies into your classes through their constructor - "injecting" them - rather than instantiate them inside the class (think data access).

Notice how I didn't involve another concept here? By "staying on target" I'm able to craft a demo that's laser-focused and doesn't waste anyone's time. Remember: this is video, rewinding is easy.

Make your point clearly with as few words as possible, and don't insult your viewer with pedantic tangents.

Code. See it.

We've crafted our demos - we know what we want to say and we haven't polluted it with opinions unless conveying the opininion is your point. Let's rock this!

We're going to do our demos in multiple takes - focusing on small, 1 - 2 minute demo increments. This lets us go backwards if we mess up.

I use Screenflow for all my recordings. It's Mac-only, but if you're on your Windows then don't even think about it and use Camtasia. The software isn't important right now - I'll cover that later.

Have your outline open in a window next to you, and think about the "takes" for your demo. You might be trying to show Dependency Injection, but don't try and cover it all at once! Slice it into smaller parts that you can do in 60 seconds or so.

If you screw up, type stupid, monkey-finger your keyboard, have your IM pop up, accidentally show your email password, or have a crash - you'll want to back up. This is why you want to do this in 60 second recording pops.

Don't Talk and Type

No one ever believes me - but this is so crucial: please don't try and speak while coding. Unless you're Ryan Bates or Scott Hanselman - you won't be able to do it. No one wants to hear your keys clicking either.

We just want to capture the code going down and working - we'll add the voice work later. It's much easier that way!

You won't believe me. So many people don't - good friends of mine who sell their screencasts still think I'm a nut when I say this! Let me just say that:

Hearing you studder while you type is not why I'm paying for your screencast. I'm not that into you, I just want to know what you know - please make this as easy as possible for me!

If you still don't believe me - just try what I'm suggesting once and listen to the difference. If you're not motivated, then perhaps you're just as good as Ryan or Scott...

Voiceover

Time to move on to voice? Not quite so fast!

There's no way you'll make it through your set of demos without realizing you forgot something. Which is OK! Embrace it and take some time to rethink your script and what you're doing!

Or maybe you screwed up and decided to redo something - STOP! Is that screwup something you can show someone? It most likely is and you should remember: failing is how people learn!

Take some time to think through what you've just done, and be happy you didn't record your voice because now... NOW you can jigger your demos to refine your story. Maybe go back and reshoot the one part that you screwed up - and you can inject it at a given point...

This, finally, is the last time that we will need to go over the script. We have to stop at some point and get the stuff out!

Next time - we record ourselves...