3 ms·

How To: Making a great screencast

63 points by csavage 16y ago

VB6_Forever 16y ago
The tip about recording the audio first is a gem
- petercooper 16y ago
  That said, people I've discussed screencasting with (nearly all in the Ruby community) have typically recommended video first then a voiceover - this includes Geoffrey Grosenbach of Peepcode (he also shares this technique in his screencast about screencasting). I tend to do everything in one take then edit out the mistakes so I haven't got an informed preference, though doing the audio first does seem to make sense from a pacing and "maintaining interest" perspective.. you can always edit down/speed up the video parts, after all. I suspect that merely being detailed enough to think about these processes and how they work (or not) for you is enough to put you above average in the screencasting stakes.
  - mhartl 16y ago
    The Rails Tutorial screencasts (http://zfer.us/EKm97 http://zfer.us/EKm97) always combine audio and video from the same take (using ScreenFlow, natch). I can't imagine achieving a good teaching cadence any other way. I also love the verisimilitude of hearing mouse clicks and keyboard clacks synchronized with the action on the screen.
jamesbritt 16y ago
Thumbs up on Screenflow. It does quite a bit for $99. I especially like how easy it is to swap in alternate takes of things. I've been using it to develop live presentations with slides, and was very helpful in working out a talk for Ignite Phoenix, where timing is extra crucial. I tend to write down some notes, then do a recording more or less ad lib, see how much I screwed up and flubbed things, and gradual get a feel for what phrasing feels most natural, what steps are needed, what I have to explain. The end result is a sort of pre-recording of your talk, which you can watch as an aid to practising and getting the whole thing into our head. Also, good point on keeping screencasts short. I hate having to jump around in some 20-minute recording trying to find where one or another item was explained. Better to break things down to a set of tighter presentations.

63 points by csavage 16y ago

VB6_Forever 16y ago

The tip about recording the audio first is a gem

petercooper 16y ago
That said, people I've discussed screencasting with (nearly all in the Ruby community) have typically recommended video first then a voiceover - this includes Geoffrey Grosenbach of Peepcode (he also shares this technique in his screencast about screencasting). I tend to do everything in one take then edit out the mistakes so I haven't got an informed preference, though doing the audio first does seem to make sense from a pacing and "maintaining interest" perspective.. you can always edit down/speed up the video parts, after all. I suspect that merely being detailed enough to think about these processes and how they work (or not) for you is enough to put you above average in the screencasting stakes.
- mhartl 16y ago
  The Rails Tutorial screencasts (http://zfer.us/EKm97 http://zfer.us/EKm97) always combine audio and video from the same take (using ScreenFlow, natch). I can't imagine achieving a good teaching cadence any other way. I also love the verisimilitude of hearing mouse clicks and keyboard clacks synchronized with the action on the screen.

jamesbritt 16y ago

Thumbs up on Screenflow. It does quite a bit for $99. I especially like how easy it is to swap in alternate takes of things. I've been using it to develop live presentations with slides, and was very helpful in working out a talk for Ignite Phoenix, where timing is extra crucial. I tend to write down some notes, then do a recording more or less ad lib, see how much I screwed up and flubbed things, and gradual get a feel for what phrasing feels most natural, what steps are needed, what I have to explain. The end result is a sort of pre-recording of your talk, which you can watch as an aid to practising and getting the whole thing into our head. Also, good point on keeping screencasts short. I hate having to jump around in some 20-minute recording trying to find where one or another item was explained. Better to break things down to a set of tighter presentations.