I'd Rather Be Writing » audiovisual

The Importance of Visual Communication, or How to Build a Dirt Sifter

Tom Johnson — Tue, 07 Sep 2010 05:28:34 +0000

Recently due to flooding in my window wells, I had to dig the wells deeper. I piled up the dirt and rocks around the outside, and then realized I needed to sift the dirt from the rocks because I wanted to put the rocks back in, but move the dirt elsewhere in my yard to re-slope it. To sift the dirt from the rocks, I needed a dirt sifter, also called a gravel sifter. I thought I could simply buy one at Home Depot, but they do not sell them. You have to make one yourself.

I searched online to find instructions to build a dirt sifter. There are plenty of sites, with no one single method for building a dirt sifter. For the most part, it involves a rectangular wood box with a wire mesh bottom. That sounds simple enough, but as I walked through Home Depot looking for these parts, I had many questions. What size should the box be? How spacious should the mesh be? Would the dirt sifter fit snugly on my wheelbarrow or slide off? Would I shake it in my hands? Would I roll it somehow? If I rolled it, did the sifter need wheels? How strong did I need to attach the wire mesh to the wood? And so on.

I did some research online to figure out how to build a dirt sifter. One guy had a sweet looking roller device on his dirt sifter, but no real instructions on how to build what he’s showing. Another site had one incredible diagram but not much else. Others failed to provide any visuals whatsoever.

It’s not enough to build a box with a mesh bottom. You have to understand exactly how you’ll be using it to sift the dirt. Shaking it manually? Using a trowel in a wheelbarrow? Somehow rolling it? If you’re shaking it in hand, you better have a plan for catching the dirt, and the whole box should be small and light. But if you’re catching it in a wheelbarrow, it needs to fit over the wheelbarrow, so it needs to be larger.

It wasn’t until I found the explanation on this site that I began to understand exactly how to build the dirt sifter. The explanation is full of photos for each step of the way. The author doesn’t assume much at all, and he even provides tips such as the following:

Nails or screws driven near the ends of a board usually cause the wood to split. Pre-drilling the screw holes will help prevent splitting.

I wasn’t born with innate handyman talent, so I needed all the info I could get. After buying the necessary resources and tools, I gathered them up in my backyard.

Gathering my tools.

I started screwing the box together. It seemed pretty easy at first. I drilled holes just like the instructions recommended.

It seemed pretty easy at first.

But then my wireless drill’s battery wore down, and I grew impatient, so I started to pound a nail in there instead. Ooops, the wood split.

The wood split when I used a nail.

I had to discard that piece of wood and use another scrap that I had a lying around the garage.

I attached the wire mesh to the wood using an metal strip I found at Home Depot. It was all pretty simple, but I was still wondering just how I would shake a box full of rocks and dirt.

Fortunately, the dirt sifter fit easily on the top of my wheelbarrow, and I could use my hand (with glove on) to sift the dirt. Here’s a short video showing how the dirt sifter works.

After watching this three minute video, doesn’t it answer all the questions of sifter mechanics that I raised earlier? Would a textual explanation be adequate or nearly as appealing to watch as the video? In my video above, you see exactly how the dirt sifter works — not so much the construction, but the mechanics of use.

I find myself moving more and more away from text when it comes to tech comm. While text is a good foundation for other materials, text simply fails to communicate and engage like visuals do. With a visual (whether an image or a video), you see so many details that you can’t convey briefly with text.

Case in point, I often help users on the phone with a specific application at work. I can listen to them describe what they’re doing, but I almost always prefer to share screens and watch them go through the process. When I do that, I can quickly spot what they’re doing wrong. Sometimes I see that the content they’re working with is copied over from Microsoft Word, or I see that they’re using an unsupported browser, or I see that they really are doing everything right and the system just has a bug in it. Visual communication is faster and more effective.

The visual communication doesn’t need to be professional grade. I’ve been making quick WordPress screencasts that take me about 5 minutes from start to finish (including the upload to Youtube), and no one has complained about the quality. I also often make customized screencast tutorials for clients. They love them. It clarifies things in so many ways, and it’s easier than writing instructions out by hand.

Text, by contrast, is tedious, cumbersome, confusing, and fails to engage the user. Text still has its place, but it’s more of a supporting actor than a lead role.

Blog Sponsors

Why Tech Comm Professors Don’t Teach Video

Tom Johnson — Tue, 27 Apr 2010 14:18:15 +0000

The other week, by invitation, I was at a Missouri State University Workshop for Teachers of Technical Writing. I presented about trends in technical communication and highlighted multimedia, particularly video, as an important trend.

Near the end of my presentation, I asked the academic audience why so many teachers don’t require students to create video (e.g., screencasts, e-learning, video tutorials) as part of their help materials. Many professors focus on documentation and design more than video, yet many end-users, as visual learners, prefer multimedia formats when they’re learning software.

My question sparked about a dozen comments, which people communicated both collectively and privately to me. It turns out one of the biggest reasons professors don’t teach video to tech writing majors is due to academic turf wars over who has rights to teach video.

One professor explained that as soon as you include the word “video” in your syllabus, the other departments, such as Film, start to object. Video is the film department’s realm. You’re pretty much confined to documentation topics for a technical writing curriculum.

Other professors ran into the same problem with the word “design.” Throw in the word design and you suddenly start a turf war with the Design department.

Professors mentioned some other reasons for not teaching video as well. Many professors aren’t familiar with video tools, so they don’t teach it. Others may be familiar with the tools, but the tools are beyond the scope of the student’s budget. Others explained that the tools change so frequently, by the time they get a curriculum approved (which may take a year or more), the tools have already changed.

Of course the same turf war sometimes happens in companies. If technical writers start producing e-learning, the instructional design or training departments may cry foul. If you start producing screencasts, the audiovisual department and voiceover talents may feel shorted.

These responses explain why audiovisual skills continue to be underdeveloped in our industry. Incoming tech comm graduates often don’t have these skills, many existing tech comm professionals don’t develop these skills, and there doesn’t seem to be a transition point at which the tech comm professional acquires the skills for video.

As such, video will continue to remain a gap among technical communicator skillsets. It’s a ridiculous trend that starts in the university and perpetuates into the professional field. It’s part of the reason why so many technical communicators continue to be “just writers.”

In response to some of the comments after my presentation, I encouraged teachers to use Jing Project (free) to record video and to focus on the oral delivery, the voiceover (the hardest part), more than the tools. But I could sense that even this route would be met with the same resistance.

Blog Sponsors

Feasibility, Believability, and Fixability: Three Reasons Not to Use a Professional Voiceover Actor

Tom Johnson — Fri, 02 Apr 2010 13:00:30 +0000

Here’s a common scenario for creating a corporate screencast. In an effort to create a screencast, the project manager writes a script, carefully storyboarding it in PowerPoint. The project manager reviews the script with a committee several times to make sure it’s perfect, and each member of the committee makes a few edits.

Finished with the script, the project manager hands the copy off to an audiovisual specialist, who creates the video by working with a professional voiceover actor. The voiceover actor reads the script in a studio, performing it with a professional-sounding voice, and the AV specialist tries to match the voice narration with video capture and mouse movements in the application. After a couple of weeks, they return the video to the project manager for review.

As the project manager reviews the script, he or she notices that the voice doesn’t quite match the mouse movements. In fact, in watching the video, it becomes clear that the voiceover actor doesn’t know the application at all. The person is merely reading copy (but reading it well, nonetheless).

The project manager also realizes, later, that edits need to be made to the script. The project manager forgot to include some notes, and other parts need to be removed. So the project manager makes changes to the script and sends it back to the AV specialist, who has to ask the voiceover actor re-record the script, and then the AV specialist needs to re-sync the audio with the mouse and screen. The whole process is so tedious it tries everyone’s patience. After two months, they have produced one short video.

I mention this scenario because it’s a commonly presumed setup for video tutorials in corporate settings. For a variety of reasons, I think it’s better to have the technical writer create the video from start to finish, rather than involving audiovisual specialists and voiceover actors. Let me elaborate with three reasons why.

Feasibility

The technical writer knows the application better than anyone else on the project team (except maybe QA). Project managers and business analysts know how the app should generally work and the customer requirements, but they lack the nitty-gritty detailed understanding that comes from writing a book on the application. Developers and engineers only understand pieces of the functionality, not the full application. Support agents understand only problem areas. But when you write a book on an application, you get to know it well.

With a solid knowledge of the app, the technical writer can quickly and easily write video scripts for the most important features and functions. The technical writer is also a writer. Most likely the technical writer has conceptual chunks and general processes he or she can repurpose from the extensive help he or she already created for the app. If not, the writer can crank out words three times as fast as anyone else, and three times as polished and articulate on the first draft.

Writers also understand how to make text sound conversational. They include contractions, remove passive voice, and have a keen sense of clarity and organization.

Most importantly, if a tech writer knows he or she will be reading the script, you can believe that the tech writer will not write stiff, rambling copy. The tech writer will write with a clear idea of exactly how stupid or believable he or she will sound reading it — and make adjustments accordingly.

Believability

If you hand off a script to a voiceover actor, he or she may read it well, but will it contain all the nuances, inflections, rhythms, and pauses necessary to explain the application’s functionality in a believable way? Voiceover actors may have incredibly versatile, trained voices, but if they don’t know what to emphasize, or where to slow down, or how the application they’re explaining really works, their narration won’t fit the content they’re describing in a 100% believable way.

Moreover, most software video tutorials demonstrate steps for important tasks. The video instructs users to click certain options on a menu, to make selections, and press certain keys to perform a task in the application. The voiceover actor can pause between steps, but the pause lengths will be a guess at best. The AV specialist will need to edit the pauses to ensure they match up with the actual mouse and click movement on the screen. This is tough to do.

And if an AV specialist is producing the video to sync with the timing of the mouse movements, the AV specialist will also need to know the application. This learning curve presents more time drain on the production of the video.

Fixability

The third advantage to having the tech writer produce the entire video is fixability. What happens when you realize, in retrospect, that your script left out an important note? What happens when developers decide to change a screen? What do you do when you realize you had the wrong button name in the script? What happens when you watch the video and just realize that it lacks interest?

If you have a third-party voiceover actor recording it, you have to send the script back to the voiceover actor to make the fixes. You hope that he or she can apply fixes to the script here and there, without having the recording sound like a hodgepodge of sounds. But submitting the updated script and waiting to receive it back may take a week at least.

Wouldn’t it have been easier if you could record fixes on the spot and make all the adjustments on the fly? You’d be able to produce a new video within the hour. It may not be as professional, but users would already be watching it.

Blog Sponsors

Embracing the New Vernacular Instead of Pursuing the Holy Grail of Single Sourcing

Tom Johnson — Thu, 22 Nov 2007 07:12:34 +0000

For a long time, I looked at help authoring tools in terms of their single sourcing ability — creating the source material in the tool, and then outputting to online help, print, and other targets. However, I’ve given up on the ideal, at least for now. I’m convinced that the new vernacular, as a SXSW podcast called it, is audio and video.

If faced with a decision between learning via written instructions or audiovisual screen demos, which would you prefer? In most situations, I prefer the audiovisual. When learning software, most users want someone to show them how, to sit beside them and walk me through the steps in a lively, dynamic way.

If audiovisual is the new vernacular (look at the proliferation of online videos, podcasts, gaming, webinars, etc.), why are we wasting so much time trying to single source between online help and printed manuals, confining ourselves to the written medium? Instead, the following deliverables might yield better user results:

A 1-2 page Quick Start Guide that gets the user up and running with the core tasks in the application.
5-10 short screen demos that show the user how to perform the tasks.
A comprehensive online help that the user can search to find further information in the instant he or she needs it.

For too long I’ve minimized the importance of the audiovisual. Captivate — the industry standard tool for creating screen demos — is actually a relatively simple application. Mastering it and integrating audiovisual into user help will take it to the next level.