Include Bugs in Screencasting

For a number of years, I’ve been doing screencasts that help to teach others how to use WordPress – the majority of my work has been done for Envato, but I’ve also done some one-on-one screencasting as well as some screencasting for smaller teams.

Personally, I think it’s a really invaluable way to show people how to get started with using a given project without having to have them trudge through the documentation that often ships with software or with the manual that walks users through how to do a certain task.

Don’t get me wrong: I’m all for documentation, but I also know that when you’re sitting in your chair amidst all of this frustration and you have no idea where to turn, flipping through pages and pages of content hoping to find a solution isn’t always the best feeling in the world.

Anyway, the neat thing about screencasting is that aside from being able to show people how to use a project, it can always be a means by which we use to teach other people how to learn a new skill.

To me, that’s a really cool thing.

But up until this year – in fact, up until my latest round of screencasting – I always worked hard to make sure each video was as pristine as possible.

I don’t know if that’s always such a good idea, though.

When I refer to a video being as pristine as possible, I’m generally talking about the production value: You know, high quality video, colors, fonts, clear vocals through a high-end microphone, and so on.

Editing a ScreencastBut there’s always been something after screen casting that have left something to be desired (at least in my opinion): They rarely, if ever show any kind of errors happening.

Bugs in Screencasting

That is, the person who is producing the screencast gets their code right every single time. I’m not saying that’s disingenuous, but I am questioning whether or not that’s an accurate thing to do.

Sure, we all want high-quality videos and we rarely want to see someone mess up whenever they are teaching us a new skill, but what if the errors were more or less part of the script of the show?

That is, what if some of the more common things that a person is likely to experience when learning whatever it is that they’re learning were built into the the actual script of the broadcast?

For Example

In the last set of screencasts that I just finished working on, there were a couple of times where there were issues with some of the PHP I had written (like mistyped variable names or things of that nature).

These are not at all uncommon to the average programmer. So why should we mask them from those who are trying to learn a new skill?

To that end, I ended up polishing the way in which I went about doing this in the screencast, but I left the mistakes in there. Once the bugs showed up on the front-end, I then used the provided stack trace to hop back into the code to isolate the problem.

In doing so, I continued to film the entire process because I think that there’s legitimate value in learning how to debug something that isn’t working.

Writing code, building things, etc., is not something that even the most seasoned programmer gets right. So why do so many tutorials, videos, and so on present it that way?

It has to be frustrating for someone who’s trying to learn. They hit a wall, they mistype a semi-colon, they forget a closing parentheses, they try to use a feature of a language that isn’t available in whatever version they have installed, and so on, and so on and there’s nothing in the video they helps them diagnose that problem.

If you’re in the business of creating screencasts or putting together material that helps users learn a new skill, think of the various places in which they may end up having a problem and use those as teaching points. Deliberately make typos, cause bugs to occur, and so on.

Ultimately, I think it will help that much more for viewers not only to learn how something should work, but how to diagnose the issue when it doesn’t work.

10 Replies to “Include Bugs in Screencasting”

  1. I couldn’t agree more, I definitely learn more from screen-casts than I do when just trying to read the docs. Actually, I think I usually find the best solution when I am able to use a combination of written tutorials, docs, and screen-casts. When it comes to bugs in the code, it actually gives me a boost of confidence when I can catch when it happens before the code is run. So, to your point of “making mistakes” on purpose I think that if well executed and thought out it CAN be beneficial.

  2. I create screencasts for a living and have participated in the “realistic” (leave the errors) conversation several times. In my experience, the tutorials that gain the most traction are fast paced and get to the point as quickly as possible. They are fast enough for intermediate/expert users to follow without getting bored, but organized well so newbies can pause and re watch if need be (that’s the beauty of video).

    That being said, I’ve been frustrated (more than once) thinking I am following a tutorial to the letter, something goes wrong … and there is no where to turn. Would it be better, for the sake of brevity, to create a separate “Basics of Troubleshooting” tutorial for newbies than to lose advanced users with intentional mistakes?

    I have mindlessly followed tutorials with errors written in and it pissed me off when they made me go fix their intentional error. I am not saying don’t do this…I am simply suggesting that if you are going to take this approach, do it tastefully and make sure users know you are making the intentional error before you do it so they can skip ahead if they want.

    Great article,

    Devil’s Advocate ;)

    1. I create screencasts for a living and have participated in the “realistic” (leave the errors) conversation several times. In my experience, the tutorials that gain the most traction are fast paced and get to the point as quickly as possible.

      Definitely agree. 

      I didn’t mean to imply every problem or issue that we have to create needs to be recorded and shared – just small, minor things here and there :).

      if you are going to take this approach, do it tastefully and make sure users know you are making the intentional error before you do it so they can skip ahead if they want.

      Amen

  3. I agree with ya!

    I know myself that when I do screencasts and “edit” out any hiccups or errors I feel disingenuous and that I’m giving people the wrong impressions a) that I don’t make mistakes (sadly this is the furthest thing from the truth ;)) b) that what I’m showing is easy and they won’t run into any problems, when in fact, problems are just part and parcel of what we do!

    Although I will say there are times when I edit out errors with the viewer in mind, i.e. watching me spend 2-3 minutes fixing something feels like I’m wasting their time. It actually means more effort for me to edit the video, then it would be to just put it out there “as is”.

    1. Although I will say there are times when I edit out errors with the viewer in mind, i.e. watching me spend 2-3 minutes fixing something feels like I’m wasting their time. It actually means more effort for me to edit the video, then it would be to just put it out there “as is”.

      Of course!

      I’d never advocate for spending that much time showing users what we’ve done while we fumble with our work to get it done correctly.

      But minor errors here or there that we may all commit are something that’s far more likely to help others feel as if we’re more human (or something).

      Good points, Ryan!

  4. I learned PHP about 2 years ago and I learned initially from watching a 109 video series on it. The person broke the videos into under 5 minutes. Each 5 minute segment wasn’t edited at all, he left in all the typos and mistakes he made while teaching it. I felt it was actually very helpful to me because I made some of the same mistakes and remembered that he did as well, which helped me solve it. I really like the idea behind it. :)

  5. For a couple of years ago, I was a huge fan of Jeffrey Way’s video tutorials, and at the time he wasn’t editing out the bugs he made, but corrected them live. It was a completely game changer for me to watch. I think it’s an important part of video code tutorials, correcting mistakes and refactoring live.

    1. Agreed – I think it’s something that I’m going to start doing in future tutorials.

      Granted, these won’t be the kind of tutorials that are, you know, showing me spending 12 minutes diagnosing a problem, but one showing going through a stack trace to isolate a problem and move rom there.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.