

Ask HN: Do you find developer screencasts useful? - chasingsparks

I am writing a few developer-oriented how-to documents for an application I have developed. A friend of mine suggested that I do several short screencasts instead (e.g. installation, customization, etc).<p>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.<p>Do you find screencasts useful? More precisely, do you find screencasts more useful than traditional how-to documents?<p>(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.)
======
Asa-Nisse
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.

~~~
russell
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.

------
tdavis
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>

~~~
chewbranca
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.

------
dirkstoop
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.

~~~
chasingsparks
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.

~~~
dirkstoop
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)

------
bcl
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.

~~~
ams6110
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.

------
jaaron
I don't mind a short screencast. In some cases, they can be particularly
useful. However, they should never replace written documentation.

------
praptak
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.

------
ericd
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.

------
grk
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.

------
aaw
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.

------
keyboard032
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.

------
pbh
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.

------
systemtrigger
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.

------
kstenson
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.

------
clueless123
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.

------
chewbranca
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.

------
mattwdelong
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.

------
assemble
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.

------
brixon
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.

------
nzmsv
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.

------
julio_the_squid
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.

------
martian
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.

------
dimarco
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.

------
mark_l_watson
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.

------
YuriNiyazov
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.

------
ct
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.

------
adam-_-
I'm a big fan of screencasts but don't use them _instead_ of documentation.

------
jonursenbach
It all goes about how the way you learn. I'd say offer both -- screencast and
a traditional how-to document.

------
Noodling
How about written docs with screen shots, some of which you can click to
animate interaction snippets?

------
pwmanagerdied
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.

~~~
tjstankus
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.

