Considering a Screencast Series
Screencasting! It’s the teaching medium that’s sweeping the nation!
I love screencasts. Certain ones, anyway. Done well they enrich understanding. Done wrong they’re a snore and a half. I’m in the middle of redesigning Jetrecord and the more I redesign the more I’m considering redoing it from the ground up (and doing some screencasts about the process).
Why? Well, I’m looking at all the shortcuts I’ve taken to get to where Jetrecord is today and frankly, it’s embarrassing. Don’t get me wrong. I LOVE Jetrecord and I think it’s both a great idea and a great product. I just think I can do better. I owe it to my customers to make it the best it can be.
I’m also one of those people who loves great foundations; well, I love the idea of great foundations. I love talking about foundations, dreaming about them, planning them, scheming. But when it comes time to build the application I get so focused on delivering a great experience and a great product that I glance right over the possibility that I may change my mind on a few foundational things, that people involved in the project come and go, that features come and go, et cetera. I know it’s impossible to plan for everything but I know there are some things I could do a whole lot better.
When I build an application I put a whole lot of time into building great user experiences (I try, anyway) and just enough time into making sure the application keeps chugging along. I tell myself, “it’s not a problem until it’s a problem,” which is a great way of looking at life for most matters. 80% of the time, we really don’t need to plan for all the contingencies we plan for. Of course, it’s that scary 20% that keeps us awake at night with a death grip on our Blackberries waiting for that 3am email from the error system. (Thanks, Internet!) An example of a 20% problem would be the current financial crisis in America. We were doing fine ignoring the underlying foundational problems for a while but now it looks like we picked the wrong year to stop sniffing glue. So when it’s a problem, it’s a real big, fat, hairy problem, with mutated teeth growing out of a tumor in your stomach.
Granted, most of us don’t encounter these problems. For small, local, mostly internal applications, applications in which we and maybe 20 other people are the only users, the 20% problems can usually be contained. It’s when we move into the realm of needing to support thousands of users in multiple countries on a 24/7 basis that we start encountering the mutant teeth kind of problems.
Jetrecord isn’t quite the super-multinational app yet but I believe it’s going there. It will, I tell you!!! Moreover, I’m at a place in its development where stopping and doing the right thing makes sense. I’m redesigning anyway and my plans already involve a better foundation. If I wait until it actually is supporting 20,000 users in 20 countries, I’ll have quite a job on my hands. I’ve racked up some code debt and it’s time to pay it off–and start saving a little.
But why do a screencast about it?
For one thing, I’ve been a code leech for most of my career. I’ve written a couple free things here and there and released them into the wild but nothing too substantial. Mostly I’ve read other people’s books and articles, attended other people’s conferences, and taken other people’s free code samples. And truly, all of these things have taught me a lot and I wouldn’t be where I am without the generosity of many, many people. But I think it’s time I did something substantial, extraordinary, and excellent for others.
Second, it’s going to force me to write the best code I can. I’m embarrassed during code reviews if there are glaring mistakes so I’m going to try hard to make sure it’s worthwhile code because it’s public. I already know I’m going to have to do a lot more research to find best practices and I’m sure I will make mistakes and I hope someone will be kind enough to suggest improvements. This will benefit me and you as coders and ultimately it will benefit the applications we build and the clients and the users we support. Win-win-win-win-win.
Lastly, I’ve been doing screencasts since 2001, since before they were called screencasts. In one of my previous jobs we were publishing “help videos” in Camtasia on our web site to show users how to use the site and some of the software products we supported. I consider myself knowledgeable enough to make a good video, or at least, to give it a go. Whether they’re actually good or not is up to you.
Having said all of that, I still haven’t fully settled this in my mind. I want to do it. I know it would be good. However, screencasts take a lot of time to do right. For every minute of production video there’s 30+ minutes of material and mistakes that don’t make it in, not to mention planning, outlines, scripts, research, creating or finding other media like music, artwork, and extra video. Then there’s editing, producing, and finding a place to host it. It’s not unlike being a T.A. in grad school. You’ve got this whole other full-time teaching job to do while you’re trying to complete your own studies. (At least, that was my experience.) It’s both fantastic and super-sucky at the same time. And you don’t get paid!
So, if the series is going to show up, it’s going to show up here on this web site, and probably very soon because I’m already building the foundation for the next Jetrecord (which is going to rock, by the way; if you’re a pilot, you should use it). If I wait too long, I definitely won’t do it.
Okay, thank you, and now for my next anti-climax…
If you decide to do screencasts, would you also consider accompanying them with a non-video format?
I assume you’re talking about coding demonstrations, right? Maybe I’m in the minority, but I don’t get what the big deal is with screencasts and coding.
They lack decent search-ability and don’t lend themselves to quick scans for the small code snippet you actually need.
They usually require sound so that I can listen to someone explain what they’re doing, which means I have to pause anything else I might be listening to, or possibly find headphones so that I don’t disturb others.
You can’t copy and paste (which comes in handy when someone uses a font that makes it impossible to tell the difference between 1s and ls, and 0s and Os).
If you need to repeat a whole step or just the last sentence, you can only attempt to rewind and hope you hit the right spot. Or if it’s a really poorly made video, you’re forced to watch again from the beginning.
I realize my experience is that I only come across screencasts when I’m just trying to leech a quick bit of code from someone else rather than to learn whole concepts. But I think the main issue for me is the search-ability factor. There’s just no way to really know if a screencast is going to contain the information I want. Maybe a really intriguing title would interest me more, but 99 percent of the time, I pass them by in favor of plain old text.
I’d be interested to hear what the case for screencasts really is though.
It’s just another teaching method. Audio/visual media hit a different part of the brain than straight text and even straight speech. There’s a theory of learning that says we all have different ways of learning. Some prefer visuals, some prefer movement, some prefer logic and perception, some need to continually ask why, some just want to memorize facts, some need to say it out loud and discuss with others, some need to write it down, and so on.
I know I learn better when I combine several methods together and that’s what I hope to do here. My model is the Head First series of books from O’Reilly even though I won’t come close to their production value. I will probably concentrate on the audio/video aspect but I will also include text and code samples. And I hope there will be discussion in the comments.
For screencasts that involve code I like movement and discussion. Move, type, discuss, repeat. Plus I sometimes pick up tricks for being more productive in my editing software, tricks that rarely come across in static text and images. It’s like having an on-demand pair programming partner give you a few tips while you write your own code.
So that’s why screencasts. To be sure, they’re not for everyone. But I know there are people out there like me who learn best by watching them, sometimes over and over again.
[...] process. That’s right. I’m going to cover the rebuilding of Jetrecord in detail in a series of screencasts aimed at developers on my personal website. I’m going to take you behind the scenes of Jetrecord and expose the internal process [...]
Gotcha. It does sound like audio/video + text/code samples + discussion in the comments would be a pretty good offering. I’ll keep an eye out for the series launch. :)
Harry,
For those of us who are looking up to your practices and experiences to build our own foundations upon, a screencast is a huge help.
It’s not unlike what we do in our blogs – we write about stuff that we already know about, or have already spoken about profusely (even if only in our own heads). The fact that we write it down though, archives it not only for our own use, but for the benefit of others as well.
While a screencast of what you’re doing may help you in allowing others to critique your work, it will help others such as myself by allowing them to see what you’re doing – and how you’re doing it.
I for one selfishly encourage you to endeavor forward.
Not to mention – if Thom Yorke has anything to do with this it will be glorious.
Thanks, Jonathan. I’ll do my best.