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.
But 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?
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.