Ask HN: Do you find developer screencasts useful?
29 comments
No. There is no way to appreciate the information communicated because I cannot take it in at my own tempo (faster / slower). It's hard too see whats going on in the cast. More important it eats my time unneccessarily.
I much more prefer screenshots with loads of text.
I much more prefer screenshots with loads of text.
Agreed. Screencasts are linear at the presenters pace. Documentation can be skimmed or probed randomly. Often I dive deep to see how a particular issue is handled.
All too often screencast production qualities are terrible: lighting sucks, the cameraman focuses on the wrong things, the pacing is wrong...
Developers are readers. It's mostly what we do: code, documentation, logs, stack traces. We are a pretty literate bunch. OTOH a video of a new tool would be more useful for a mechanic than the usual postcard description.
That being said, good graphics help a lot. I found the Wikipedia sort demos wonderful.
All too often screencast production qualities are terrible: lighting sucks, the cameraman focuses on the wrong things, the pacing is wrong...
Developers are readers. It's mostly what we do: code, documentation, logs, stack traces. We are a pretty literate bunch. OTOH a video of a new tool would be more useful for a mechanic than the usual postcard description.
That being said, good graphics help a lot. I found the Wikipedia sort demos wonderful.
I agree - I can't grep screencasts, so while they may be sort of useful once, after that they're just annoying. In terms of information/byte, they are vastly inferior to screenshots + well written documentation.
Agreed. Also, audio can be quite intrusive meaning that you then have to find an appropriate time to view them.
Actually in QuickTime player (not sure about others) you can adjust the playback speed. Command-K will bring up A/V controls and you can speed or slow it without affecting pitch.
I use this trick often when watching developer screencasts.
I use this trick often when watching developer screencasts.
Screencasts can definitely be useful! Take the Compass screencast[1] for instance. When I first watched it I had no intention of using SaSS/Compass right then; it took me a few more months to find an opportunity to make use of it. What I did learn were the basics from a user's perspective. Sure, I could have read the API docs and browsed some example files, but why would I go to all that effort if I just wanted a gentle introduction to what it could do for me?
I've tried watching other screencasts which try to actually teach you how to do something and I have a tendency to forget them almost immediately. Take a subject like Vim: it's much more efficient to provide tips in text if you actually want to teach people how to use them. I'm not going to pause a video and try to make muscle memory for commands right then, but I might remember a tip on how to do X and reference a blog post later.
It's the difference between an "intro to X" and "how to do Y in X". Screencasts are great for gentle introductions; they're very difficult to make for anything more granular.
[1] http://wiki.github.com/chriseppstein/compass
I've tried watching other screencasts which try to actually teach you how to do something and I have a tendency to forget them almost immediately. Take a subject like Vim: it's much more efficient to provide tips in text if you actually want to teach people how to use them. I'm not going to pause a video and try to make muscle memory for commands right then, but I might remember a tip on how to do X and reference a blog post later.
It's the difference between an "intro to X" and "how to do Y in X". Screencasts are great for gentle introductions; they're very difficult to make for anything more granular.
[1] http://wiki.github.com/chriseppstein/compass
I'm sorry, the compass screencast was informative and interesting, but it was a marathon screencast that I lost focus on at least 17 times before it finally finished.
Jacob Kaplan-Moss recently wrote a series of really good articles about writing good documentation, I highly recommend reading them if you're about to embark on making technical docs:
http://jacobian.org/writing/great-documentation/
He subdivides documentation as a whole into more or less the following three sections:
- Tutorials
- Topical Guides
- Reference
Screencasts can work for Tutorials, and they can be used for marketing purposes, in which they're closer to topical guides but probably won't provide as much depth as a textual guide could.
Imho. a screencast can be great as a marketing tool, but not so much as a learning tool.
http://jacobian.org/writing/great-documentation/
He subdivides documentation as a whole into more or less the following three sections:
- Tutorials
- Topical Guides
- Reference
Screencasts can work for Tutorials, and they can be used for marketing purposes, in which they're closer to topical guides but probably won't provide as much depth as a textual guide could.
Imho. a screencast can be great as a marketing tool, but not so much as a learning tool.
Jacob's docs were fantastic. I read them after they were posted on HN a few weeks back.
The marketing aspect is pretty important. I was considering following his (my friend's) advice for that reason. Every week or so there seems to be a "Watch me build a blog in 5 minutes" screencast. I don't really think they are tutorials; they are closer to movie trailers.
The marketing aspect is pretty important. I was considering following his (my friend's) advice for that reason. Every week or so there seems to be a "Watch me build a blog in 5 minutes" screencast. I don't really think they are tutorials; they are closer to movie trailers.
I agree, I remember seeing some old RoR screencasts a couple years back, thinking: That editor is awesome. That's what made buy a copy of TextMate. (I still haven't ever used RoR tho)
I don't like them. With a screencast I have to sit through it at the pace of the presenter. With an article I can read at my own pace and skim it if needed.
ETA: Good point below, screenshots enhance an article more than a screencast would, for me anyway.
ETA: Good point below, screenshots enhance an article more than a screencast would, for me anyway.
I find a written document, perhaps augmented with screenshots, to be most helpful. Screencasts, by themselves, I find to be next to useless. A screencast demands investment of significant time before one can even determine whether its going to be helpful. With a written document, it's usually possible to tell from the first paragraph or a quick skim if it's something worth spending more time on.
Screencasts are undoubtedly faster and easier to prepare than a written document, perhaps that's why I tend to see so many involving technologies such as CMS platforms that cater to folks who want quick solutions that they don't need to understand very deeply.
Screencasts are undoubtedly faster and easier to prepare than a written document, perhaps that's why I tend to see so many involving technologies such as CMS platforms that cater to folks who want quick solutions that they don't need to understand very deeply.
Especially bad is when the presenter shows a desktop for the first 2 or 3 minutes while talking about what they are going to be talking about.
I don't mind a short screencast. In some cases, they can be particularly useful. However, they should never replace written documentation.
No navigation, no copy/paste, fixed speed, hard to do in parallel with actually monkeying with the product (the best way to learn anything :) ).
They might have a niche for things that are heavily GUI-oriented. Click there, drag this from here to there, slide this slider - this is where I think screencasts might be both faster and clearer than narration + screenshots. But that's rather user- than developer-oriented.
They might have a niche for things that are heavily GUI-oriented. Click there, drag this from here to there, slide this slider - this is where I think screencasts might be both faster and clearer than narration + screenshots. But that's rather user- than developer-oriented.
Ryan Bates' Railscasts (http://railscasts.com/) are uniformly excellent short introductions to different topics, and a great example of how to do screencasts right. They're short, give a quick overview of a new and relevant topic, and you can pick up a lot of little tips and tricks on how to develop in general as you watch him code (especially if you use the same tools).
They're a great way to get jumpstarted on something you've never approached, after which you're in the right frame of mind to jump into the docs, since you will have grokked the general overview of the topic from Ryan's short summary. YMMV, but I find it much easier to get an overview quickly than hitting a pile of docs cold.
They're a great way to get jumpstarted on something you've never approached, after which you're in the right frame of mind to jump into the docs, since you will have grokked the general overview of the topic from Ryan's short summary. YMMV, but I find it much easier to get an overview quickly than hitting a pile of docs cold.
I used to watch a lot of screencasts in the past years because of ~1 hour bus+train commute to work. It's a great tool to check out new things, or to get a fast intro. In this way, I enjoyed the New Relic screencasts - they were more about the general idea of how things work, not specific implementations.
For figuring out how to do something, I find Railscasts great. But that's partly because when I want copy/paste and search, I can always go to ASCIIcasts.
So, to for your problem: I'd like to be able to watch a screencast explaining the general idea of the app and a quick intro to developing with it, but for the specifics, stick to text.
For figuring out how to do something, I find Railscasts great. But that's partly because when I want copy/paste and search, I can always go to ASCIIcasts.
So, to for your problem: I'd like to be able to watch a screencast explaining the general idea of the app and a quick intro to developing with it, but for the specifics, stick to text.
I'd spend more time on the written docs, and I definitely wouldn't replace written docs with screencasts. Especially for how-to documentation, people want to skim first, then go back and follow the steps themselves, and the latter part is more difficult with a screencast.
As a side note, I only really watch screencasts for stuff that I'm already very interested in. Watching a video means plugging in/finding headphones if I'm in the office and making a commitment of a couple of minutes.
As a side note, I only really watch screencasts for stuff that I'm already very interested in. Watching a video means plugging in/finding headphones if I'm in the office and making a commitment of a couple of minutes.
Yes, I do -- and I like 'em a lot. Although, not for everything. I love railscasts.com because of their concise and properly paced screencasts. Peepcode's, not so much. They try to cover way too much in a very short span. With that being said, I don't see them as a replacement for documention (for obvious reasons), but sometimes a 5-10 minute screencast showing a feature can be easier & funner than spending 30 minutes bouncing around documentation.
Screencasts seem to me like they are the right tool for explaining standard paths through complex user interfaces. This is especially true of poorly documented and/or very open ended interfaces (e.g., in my case, Emacs or Photoshop). (For example, I only realised that I could open a remote MySQL prompt through SQL-mode, using TRAMP, after watching a screencast.) That said, in the same way that people argue that good naming practices should obviate the need for many comments, I worry that people use screencasts as a crutch to avoid implementing needed usability improvements.
I think screencasts also guarantee that your thing sort of works, which adds an air of professionalism.
That said, gripes include: hard/impossible to speed up while watching, hard/impossible to bookmark a specific spot, hard/impossible to skip over bits that you already know, requires headphones/speakers/video, often hard to see what's going on, and easily goes out of date.
I think screencasts also guarantee that your thing sort of works, which adds an air of professionalism.
That said, gripes include: hard/impossible to speed up while watching, hard/impossible to bookmark a specific spot, hard/impossible to skip over bits that you already know, requires headphones/speakers/video, often hard to see what's going on, and easily goes out of date.
In video, your failures are magnified. As with text it comes down to quality, taste and respect for the viewer. The default in video is poor quality because poor quality is easier to make. Screencasts can be much more powerful than text, after all you have more tools at your disposal - you get to play with audio and the pictures move. The trouble is, to make great video you have to think very carefully about how you want to convey your message. How tight is your delivery? Is it well edited or can I hear you breathing into the microphone? Most people are terrible at delivering on even these basics of video. For people who respect the medium producing screencasts can be time well spent. Consider that there are right now myriad untapped markets on the web in which you can teach via video and charge for quality downloads.
I think screencasts are as good as the presenter. The best screencasts are much like a good 10 min pitch. They should tell me the problem, show me the solution and leave me excited and wanting to find out more!
One of my favorite ever screencasts was Rob Conery's on BDD with C# with the MSpec framework[http://blog.wekeroad.com/mvc-storefront/kona-3/] It was put together so succinctly that it really clicked with me what BDD was all about and I came away wanting to download the tools and learn more!
If your screen cast is on Vimeo you could add the little bookmarks on the video time line. This could help users skips to sections appropriate to them.
One of my favorite ever screencasts was Rob Conery's on BDD with C# with the MSpec framework[http://blog.wekeroad.com/mvc-storefront/kona-3/] It was put together so succinctly that it really clicked with me what BDD was all about and I came away wanting to download the tools and learn more!
If your screen cast is on Vimeo you could add the little bookmarks on the video time line. This could help users skips to sections appropriate to them.
IMHO, you can communicate a whole lot of information on a short screencast * if * it is well done. Like a long winding documents screencasts can be a bore.
In my experience.. a well done screencast usually takes me longer to do that a written document.
In my experience.. a well done screencast usually takes me longer to do that a written document.
Screen casts are usually hit or miss for me, but I have really enjoyed watching railscasts.com. I have learned a lot from those screencasts and I find that its easier to grep screencasts after you are more familiar with the authors style.
Yes, and no.
When I am beginning a subject of interest, I find screencasts to be exceptionally useful because I am a visual learner; however, there is a point that I reach in which screencasts become a hindrance opposed to a useful tool. To define that point precisely is a bit difficult, but if I had to I would say it`s the point at which I know enough on the topic to transition into 'hands on' learning. At that point, I find textual references far more useful and videos just slow me down. Of course, most of these points have already been touched on, but I figured I could back them up. More data is never a bad thing.
When I am beginning a subject of interest, I find screencasts to be exceptionally useful because I am a visual learner; however, there is a point that I reach in which screencasts become a hindrance opposed to a useful tool. To define that point precisely is a bit difficult, but if I had to I would say it`s the point at which I know enough on the topic to transition into 'hands on' learning. At that point, I find textual references far more useful and videos just slow me down. Of course, most of these points have already been touched on, but I figured I could back them up. More data is never a bad thing.
No, I hate screencasts for several reasons.
- I can't stream video at work. I can read documentation all day long, but streaming video, audio, etc. is not a valid use of company resources.
- I can't easily find the information I need. Video is not searchable, and it's difficult to just skip to the right spot.
- Documents can work as a reference. A lot of tutorials are good enough to be reference materials, especially when the thing they document is lacking in the documentation department.
- I don't like listening to people talk to me, I read at least 10x faster than somebody can talk to me.
- I can't stream video at work. I can read documentation all day long, but streaming video, audio, etc. is not a valid use of company resources.
- I can't easily find the information I need. Video is not searchable, and it's difficult to just skip to the right spot.
- Documents can work as a reference. A lot of tutorials are good enough to be reference materials, especially when the thing they document is lacking in the documentation department.
- I don't like listening to people talk to me, I read at least 10x faster than somebody can talk to me.
End users love them. Think how much TV people watch vs. how many books they read.
For developers, use them for intro's and beginner material, but not a primary reference. Developers read a lot more than normal people.
For developers, use them for intro's and beginner material, but not a primary reference. Developers read a lot more than normal people.
What if instead of doing a traditional screencast or traditional howto, you create a hybrid. A how-to document with a short video explaining each section of text. That way steps that are trivial can just be read through, and where a demonstration is needed, the user can watch the video.
The problem is, of course, that few people will find the same steps trivial, so you'll have to do double the work (video and text). On the other hand, this will solve the problem of pacing.
The problem is, of course, that few people will find the same steps trivial, so you'll have to do double the work (video and text). On the other hand, this will solve the problem of pacing.
I don't find screencasts useful, I suppose for the same reason I don't like video interviews. It requires a different sort of attention than text and is more time consuming. There's no cut and paste for code in screencasts, and I find it difficult to follow the flow of tutorials. I guess I'm not a video oriented person - I don't have a TV and don't watch much on the computer. I'd prefer normal text documentation any day.
Screencasts are helpful for me, but only in a few settings and with one major caveat: There should be little if any transition/fade/time-lapse in the video. A discontinuity of presentation can really make it difficult to follow what is happening.
And I agree with many other folks here that a screencast should best be used for an introduction to a subject, and that it can never replace detailed documentation.
And I agree with many other folks here that a screencast should best be used for an introduction to a subject, and that it can never replace detailed documentation.
If it's a screencast for a framework, I'm all for it. Example being RoR. There are so many different files and different steps to take to get things moving, that hearing somebody else talk about it makes it easier for me.
If your how-to documents are doing anything like teaching RoR, then I'd recommend a screencast or 2.
If your how-to documents are doing anything like teaching RoR, then I'd recommend a screencast or 2.
A few are, but in general I like two types of blogs:
1. how-to articles that solve specific development problems I have run into
2. thought-articles that expose me to a different point of view, even if I don't entirely agree with it
I have enjoyed screencasts on slime+emacs use and some rails stuff.
1. how-to articles that solve specific development problems I have run into
2. thought-articles that expose me to a different point of view, even if I don't entirely agree with it
I have enjoyed screencasts on slime+emacs use and some rails stuff.
I like them in a specific situation - when I am taking a break from coding, and want to learn something new that may or may not be related to my immediate task, I prefer screencasts - video gives your eyes a rest from text, but you can still claim that you are productive in a way.
I'd rather be able to skim and search/jump around through text than have to read through a video. Plus videos typically are fuzzy and hard to read what needs to be typed (I can't just copy/paste), and are a waste of bandwidth.
I'm a big fan of screencasts but don't use them _instead_ of documentation.
It all goes about how the way you learn. I'd say offer both -- screencast and a traditional how-to document.
How about written docs with screen shots, some of which you can click to animate interaction snippets?
I find screencasts most useful for getting a feel for new software relatively quickly. Seeing how an experienced used does things can get you started a lot faster than reading through docs until things click. To me their utility begins to decline after this.
I'm with you. I like screencasts for getting started with a new tool but once I'm up and running I tend to reach for in-depth written documentation or reference materials.
But, this makes screencasts really valuable IMO. When you have an hour to evaluate something a screencast seems more useful than a massive book.
But, this makes screencasts really valuable IMO. When you have an hour to evaluate something a screencast seems more useful than a massive book.
[deleted]
I dislike screencasts but they seem to be awfully popular. Since I don't have the sufficient Karma to run a poll, I want to get some general feedback from HN developers.
Do you find screencasts useful? More precisely, do you find screencasts more useful than traditional how-to documents?
(It's a tough question to answer without specific context of the topic, but I'd rather not ask with context -- the responses are typically more illuminating.)