I'd Rather Be Writing » screencast

Building on Past Successes for Future Directions

Tom Johnson — Wed, 13 Jul 2011 06:56:39 +0000

The many directions one can go

I have a lot of flexibility and freedom in my job. That’s part of the appeal. The other day I was reflecting on the best route to take, the most fruitful path I should follow.

There are quite a few directions I could go. I could become meticulously detailed about style, knowing the ins and outs of every handbook (and being able to compare them with wit and perspective). I could become a tools guru in skinning online help, branding it with the right look and feel for our department. I could become a content producer, immersing myself in the product to write longer, more comprehensive topics.

Or I could become a SME project leader, organizing the writing efforts of a dozen or more subject matter experts (SMEs). I could become a manager, leading and inspiring my team. I could become a champion for usability, inserting myself into the design process and working towards better interfaces. I could become a content management specialist, managing the content for an entire team. I could become a community leader, or a single source champion, a taxonomist, a metadata specialist, a content strategist, a failing fiction writer, and many other things as well.

After reflecting on directions, I decided to focus on past successes. By successes, I mean those things from which I constantly hear praising feedback from customers. My main successes in tech comm have been with the following:

Quick reference guides
Screencasts

My longer documentation is fine, but no one ever writes in to say how much they enjoyed the user manual. In contrast, quick reference guides win users over every time, and screencasts actually show them how to use the product. People are always submitting feedback about how helpful the video tutorials were.

Outside of work, my two main successes have been as follows:

Blogging
Podcasting

Writing is my core strength, especially the blog format. And podcasts — well, I seem to go in spurts with them. I don’t think I’m a particularly good podcaster — I just happen to be one of the few people recording podcasts in tech comm. Regardless, I love the conversations and connections I make in my podcasts. That professional interaction is rewarding.

Of all the above, I think screencasts hold the most promising future. I plan to move more fully in this direction for several reasons:

I prefer to learn software by video (for example, by watching the videos at lynda.com). Text makes sense for a lot of things, but when people are learning software from ground zero (rather than searching for a specific question), visual learners prefer video more than text.
Videos are something others cannot usually do. Everyone seems to think they can write, but few can actually record a screencast. This ensures that I’m putting effort into a skill that can’t easily be replaced or outsourced.
Video has a lot of room for growth. I can learn so much about audio and video themselves. I want to learn After Effects so that I can better demonstrate concepts. This would be a powerful skill.

My screencasting prowess is only mediocre at best. Eventually I’d like to get good enough to create videos such as the WordPress release videos, or Mailchimp’s tutorials. I think there’s a high demand for people who can create this type of content.

That said, I’m also fascinated by findability, and there’s still so much here I haven’t explored. Even though it’s not my strength, perhaps I’ll add it as a key area of focus.

That’s me: quick reference guides, screencasts, blogging, podcasting, and findability. I guess that narrows it down enough. What’s your specialization?

——————-

photo from Flickr

Blog Sponsors

Screencasting Tip: Self-Dub the Audio

Tom Johnson — Sun, 26 Dec 2010 17:41:29 +0000

One of the most difficult elements of screencasting is getting good audio. I implemented a technique in my last video that I thought worked quite well. I’m calling this the Self-Dub technique. Here’s what you do. Whether you write out a script beforehand or not, it doesn’t really matter. Just record the screencast while simultaneously narrating. After the screencast, proceed through each of the sentences and dub over them.

For example, listen to about 10 seconds of audio, then silence the selection. Re-record that sentence with a new voice narration and add insert it there. It sounds tedious, but you can make your way through a three-minute screencast in about 30 minutes. You can voice-dub everything, even the parts that sound good. This may allow for a more seamless replacement. (If the audio you’re dubbing sounds seamless with the existing audio, then you can only dub the parts you want.)

When you’re done, you’ll have a bunch of little 10 second audio clips strung together. In Camtasia Studio, go to File > Produce Special and export the audio. Then clean up the audio a bit and reimport it back into the screencast, deleting all the little 10 second audio clips. The result is a clean audio script that perfectly fits the timing of the screen actions.

The seamless match with the timing is main advantage of using this method. If you weren’t recording a screencast, this technique probably wouldn’t make much sense. But screencasts, at least the software tutorial kind, have intricate timing between the mouse actions and the voice. The voice has to describe exactly what you’re doing on the screen in the moment you’re doing it. This Voice-Dub technique allows you to preserve the timing while simultaneously cleaning up the audio.

Blog Sponsors

What makes a good screencast? by Communications from DMN

Tom Johnson — Sun, 03 Aug 2008 07:19:00 +0000

What makes a good screencast? by Communications from DMN.

Jing Screencast: Getting Up and Running with Jing

Tom Johnson — Tue, 12 Feb 2008 13:54:43 +0000

In this Jing video tutorial, I explain how to get up and running with Jing. What’s Jing? Check out my previous post that includes several sample Jing videos showing how technical writers can benefit from Jing. You can also see the

[kml_flashembed movie="http://idratherbewriting.com/screencasts/jingEXPRESS/jingEXPRESS.swf" height="335" width="420" /]

Note: If you’re seeing some bracketed text and a link rather than a video player, it’s because the flash-embed plugin I’m using to embed the Camtasia video into WordPress doesn’t display in your feedreader. View this original post to watch the screencast.

Additional Resources

(If you listen to the Jing screencasts on their blog, you’ll hear Anton’ s unforgettable German accent.)

IT Author Podcast — Two Podcasts on Flare, One on the Making of a Technical Writer, and a Dogcast on User Psychology

Tom Johnson — Mon, 12 Nov 2007 06:11:04 +0000

I listened to Alistair Christie’s IT Author podcast the other day online and then later driving home from work. Alistair is based in Scotland and has one of the most enjoyable podcasts on technical communication around. If you listen to podcasts, add his podcast to your feed. His latest episodes are as follows:

In Flare: the good stuff, he explains the features of Flare that he really enjoys, such as being able to integrate his own javascript and PHP scripts directly into the code.
In Why do we use Flare?, he and a colleague talk about Flare in depth — for about an hour, actually, discussing the little things that annoy them about Flare, such as the visual editor.
In What does it take to be a technical writer (a carcast), he mentions some key qualities technical writers need, such as a curiosity for learning and understanding how things work.
In his May 19th Dogcast, he actually gives the podcast while walking his dog. The podcast covers the evolution of help, the need for technical communication, and user psychology.

Although the dogcast started out slow, this was the podcast I enjoyed the most. About 15 minutes into the podcast, he really hit his rhythm and started driving down into the topic that seemed to grip him most: user psychology. Users don’t read manuals. The days where long, printed manuals were standard prerequisites to using technology are gone. People experiment with an application and try to learn by doing; when they need information, they search for information about the task they’re trying to accomplish in that instant. Online help is critical in helping users find a single piece of instruction for an immediate need.

Users are also in a state of anger and impatience when they turn to the help. They’re mad because the software has frustrated them and stopped their work. They don’t want to read a manual. What they really want is someone to explain to them how to do something.

Listening to Alistair’s thoughts on the user’s state of mind made me think about the help we write. Why is it that we often begin a software documentation project by documenting all the tasks that users can possibly do from all the available functions of the software application? We spend the bulk off our time creating written instructions that almost no one wants or reads.

Instead, I think we should be focusing on several key deliverables:

Audiovisual tutorials or screencasts
Short getting started guides covering the basics
Context-sensitive online help

Further, we should begin by getting to know our user — not through a description from the SME or business analyst, but actually contacting the user to determine the tasks they want to accomplish and the format for the help.

The Getting Started guide should walk them through the most common, basic tasks the user will need to perform. This guide should be easy to get through. Alistair says the help should provide immediate rewards to the user. Take them through some quick wins. In the Getting Started guide, you give them easy-to-perform tasks that make them successful.

The screencasts (which should also be short) provide a range of other benefits, such as providing the experience of a friend showing them how to use the application.

The context-sensitive online help gives the user immediate information about the task at hand. The online help also provides a searchable database for answers.

So often we begin with the comprehensive manual in mind, when that’s the last priority for users.

Additional Resources

A few months ago I posted some notes from a Kathy Sierra presentation that talked about the user’s state of mind as well.