h1

New Media: Lessons Learned – Part 1

March 31, 2010

For those following my endeavors to think outside the book, you know all about my team’s foray into new media – blogs, Twitter, YouTube, screencasts and the like.  The software product is about to be released. We’ve set up a Google Group to encourage user collaboration. We’ve connected a blog right to the software interface so users are guaranteed the latest product information. We’ve designed an online help system that – for the first time – can be updated outside of the software release schedule.  We’ve provided both written and recorded information, so users can find what they need to successfully use this product in a variety of ways.

It’s been an exciting endeavor that made me long for Mondays.

I thought I’d list some of the lessons I’ve learned. Admittedly, some may strike you as obvious – that’s a good thing. These lessons weren’t so obvious at first blush.  I’ll devote this post to the video production effort.

Lesson 1: Real time isn’t always the best timing

The first batch of software screencasts I delivered was recorded straight from the software User Guide. I simply followed the task as written, capturing screens, mouse clicks and key strokes along the way. None of these videos were narrated. Some of these procedures took no more than thirty or forty seconds to complete.  But users viewing those first videos couldn’t follow the action.

To emphasize both user- and software- actions, I had to modify the raw footage with text captions, call-outs, highlight boxes and slooooooooow down the timing.   For a task that took about thirty seconds to complete, its corresponding video took hours to edit.

In the latest batch of screencasts, we decided to narrate all of them. Narration replaces text captions in many cases, but requires even more reliance on highlight boxes to draw viewers’ attention to the on-screen activity. Narration also introduces a host of new issues…

Lesson 2:  Recording your own voice isn’t as scary as I thought

Narration is a special skill. It’s much more than merely reading aloud. Don’t take my word for it. Visit Tom Johnson’s blog and read his series on the subject.  Narration requires someone who can inject a bit of life into dull, dry yet confusing and complex technical matter. My personal hero? View any of the videos over at CommonCraft for one of the best voices in the business.

I was born and raised in Flushing, New York, a town that’s about as attractive as it sounds. I not only have all the bad habits of a New Yawka like dropping Rs and Gs, speaking too fast, and extending vowel sounds, I also have a nasal sound frequently compared to Fran Drescher’s.  In my working life, I have had not one, but two managers complain about my speech habits. The first stood up in a staff meeting, took a marker to the white board and wrote the word, drawer – ing, calling everyone’s attention to the way I say, drawing.   (I resigned from that job soon after.)  The second manager told me during a performance review that I sound “uneducated and thug-like” and directed me to corrective speech therapy. I investigated this therapy and when I handed the manager the cost estimate (thousands!), that was the last I heard about it.

My first attempt recording this:  “This the CA ARCserve D2D Getting Started video”

sounded more like this: “This is the sea ay ahk serve dee da dee gettin’ stahted video”

Words like explore sounded like explaw, error became era.  Stuttering abounded. It was ninth grade speech class all over again – a completely humiliating disaster.

But I (refused to say no to my boss in this economy) persevered.  I learned that with a bit of practice and conscious effort to slow down my speech and not drop consonants, the rest of it wasn’t that bad. In fact, I was asked to narrate ALL the videos for product release.  Believe me, I’m not ready for Hollywood movie trailers (“In a world where a technical instruction meets high technology, one technical writer…) nor am I of Common Craft caliber.  But I’m not nearly as bad as I thought, so don’t let your own voice frighten you away from recording narration. If I can do this, anybody can.

Lesson 3:  Pre- and Post-production require a time investment

There are different tools out there for recording screencasts. Some people like to embed screen captures on PowerPoint slides and record them. Others like to use screen capture tools.  Regardless of the tool used, you’ll need to plan your project well.  For the first video I recorded, I sat down at the keyboard and pressed Record. I then had to weed out all the screen captures of error and warning messages that the tool recorded because I tried to wing it.

Now, I plot out a storyboard for each video. Nothing fancy – just an Excel file. I list what screen I want to show, jot down the narration I plan to record for it and whether any additional elements are needed, like highlights or zoom.  I also prepare the environment.  I’m recording software usage, so I want to show the software in the best possible light. That means no error messages unless I am recording a troubleshooting task.  I make sure the hard drive has enough space on it. I turn off any programs that may interrupt the recording process like Instant Messenger or eMail Alerts. I work through the procedure several times, looking for the best process to record.

For this latest batch of videos, I passed the scripts around for review before I recorded anything. In a software development environment, the interface I am recording changes with the tide. I’ve found it helpful to ask developers prior to recording whether a feature or link on the interface is about to change. If so, I save that video for last.

After scripts are reviewed, I record the task first and then do a second pass for the narration. Tools like Captivate and Camtasia permit you to record voice and screens in a single pass. But “fixing” my voice requires so much concentration, I prefer recording the narration separately, screen by screen. We’d originally allotted a week for this, but then I came down with a cold.

Addendum: reserve a quiet conference room to do some of the editing.

Lesson 4: Plan for Illness in the Project Schedule

I mentioned I sound like Fran Drescher, right? Okay, now imagine Fran Drescher with a cold. I alerted the project team that my voice may not be narration-worthy (Yeah. I see you rolling your eyes) by the deadline and someone else might have to be picked.  When I picked my head up from my wad of tissues, I was alone in the conference room with a few tumbleweeds.

I took that as a sign I’d be narrating these videos when I felt up to it.

So, I proceeded with my plan: record screens first according to the scripts.  I used some of the time I’d have spent recording voice to do some post-production work, like add in highlights and zooms, or adjust timing. I also typed the portion of the script into the notes field per screen.  When I record narration, I go screen by screen.  I like this technique because it makes it much easier to edit out any problems later.

A week after my symptoms appeared, I felt well enough to attempt narration. Since I sit in a cubicle, surrounded by sales reps on speaker phones all day, I record narration from my home.  For the first batch, I used a very low-tech set-up. I sat on my bed with a blanket over my head. And it worked. But this time, I’m using a headset/mic device. The blanket over my head doesn’t work well with the headset.  (See Tom Johnson’s blog, above, for more audio tips.)  I just sat in a quiet room this time.

I had some audio challenges. I’d recorded three videos and suddenly the fourth turned all hissy. I put work aside for the evening and when I returned to it the next day, it was fine. I don’t know what caused that problem.  It could have been network-related. At first, I’d suspected my brand new headset broke, but it seems fine now.  I was able to successfully record narration for all videos on the plan.  With Wednesday and Thursday evenings devoted to recording narration, I had all day Friday to edit.

Lesson 5:  Editing hurts

I mean physically.  I’d been wearing the headset apparatus for about ten hours a day for the past three days.  My ears hurt so badly, I couldn’t press a phone to them.  In hindsight, I won’t buy a headset-mounted mic again. I prefer a standalone mic.  Due to my cubicle environment, I had to listen to the audio with the headset to sync playback to the audio. The conference calls and office shenanigans taking place around me tend to make this task rather difficult with external speakers.

Now you understand the addendum to Lesson 3.

By 6:30 Friday, I was done. All videos scripted, recorded and narrated. They are currently in review.  As my project team reviews each video, I expect them to request some changes. If an element on the interface is changed or I’ve used the wrong word somewhere, I can easily do spot corrections to a video project.  With the first batch of videos, we realized we were missing a general overview and added that to the schedule.

In this batch, I think we’re missing the product story. It’s great to show task performance, but we need something that illustrates the benefits. That’s not on the project schedule but I’m doing it anyway.

Just in case.

Next up:  Lessons Learned from Setting Up a User Group

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: