Just about any authoring tool, including Microsoft Word, has the capacity for using a template.

Templates address three basic levels of formatting:

Page addresses parameters for page size, margins, headers and footers, and so on.

Paragraph controls the typeface and size, line spacing and space between paragraphs, along with indents and justification. Paragraph formatting can also be used to set automatic numbering or bullets.

Character is used to apply bolding, italics, underlining and any other special formatting for a single character, word or group of words within a paragraph.

The advantages of using a template are many:

Speed: Formatting with a template tag usually requires a single click.

Consistency: All documents formatted with the same template have the same look and feel.

Clarity: A well-designed template will enhance the communication for the reader, whether it is for a technical manual, quick start guide or any other type of documentation intended for the user.

Ease of update: With a well-made template, it doesn’t matter whether the same writer does the updates or someone else, because there won’t be an issue of trying to match the formatting or figuring out how (or even why) the writer used the formatting he or she did.

- Su

But sometimes technology fails us. Hardware breaks, software crashes, power goes out, a cable comes loose… the caprices of technology and vagaries of life are infinite, virtually or otherwise.

However, there is one vital action that safeguards our work against all but extreme acts of nature.

Save frequently.

When writing or editing on the computer, save your work frequently. Most PC programs use CTRL S to save. Train your fingers to use this or whatever save command is available in your application. Train your fingers to automatically press the save command key sequence after every major edit, or every time you go to a new column or page or reach for your coffee. DO NOT DEPEND ON THE AUTO-SAVE FEATURE to do your saving for you. Restoring a document off an auto-save version can be messy and incomplete.

There is nothing quite as frustrating as to be on a roll with writing or editing, where all the right words are suddenly falling into place, the language is flowing and all is right with the universe, then—bamm!—something breaks, and that 30 minutes of sheer genius you just experienced has gone to bit heaven. And that’s the kind of moment when these things usually happen.

So save frequently. Save every time you move from one application to another. Save every time you get up from your chair. Save when you sneeze. Save when the phone rings. But save AT LEAST every 15 minutes and you are unlikely to ever lose a large part of your work.

-Su

Estimating what a tech writing job will cost involves a number of factors that range from the audience you are writing for to the responsiveness of the review team and the number of reviewers on a technical document. The simplest way for a tech writer to approach a documentation project when estimating costs is to start with the end product and work backward.

Something to keep in mind always when working out the content on a project is the 20/80 rule: Eighty percent of the users will use twenty percent of the features. This is important to keep in mind because this drives the amount of content to be included, which is a very important element in costs.

Another key element is the availability of subject matter experts, or SMEs. How available are the SMEs? Are they the preliminary interview subjects only, or are they also part of the review team?

Reviews are also important to consider when estimating the cost of a job. A short review lineup will always keep costs down compared to a document-by-committee review. The more reviewers stirring the doc pot, the more likely you will have conflicting opinions, which translate exponentially to extended time and frequent rewrites and rewrites of the rewrites.

When I estimate a job, part of what I do is alchemy. I’ve been doing this kind of work for so long that my “guesstimates” tend to be fairly accurate. The only area that is hard to predict for me is the review line when working with a new client.

-Su

A couple of weeks after I started, the supervisor called me in for a review meeting to find out how things were going.

I started to describe the direction I felt the documentation needed to go.

He interrupted me. “Where are the pages you’ve done?”

Pages? “You mean my notes?” I said.

“No. I want pages. Paper by the pound. You know, poundage.”

Poundage?

“I want poundage,” he repeated. “I don’t care if the procedures are right or wrong. Nobody’s ever going to read the manuals anyway. But we’re spending a lot of money on your writing team, and I need to justify that expense. I can only do that with poundage.”

My team and I started turning out pages. When the supervisor would come by to see our work, he wouldn’t read it, he’d just pick up the dot-matrix printout and heft the weight, perforations and all. The heavier the pile, the happier he was.

I didn’t like it though. I’d been writing articles and fiction for a decade, and I was accustomed to audiences. I wanted to satisfy the audience even if it wasn’t entertainment. So despite the poundage demand, I made a point of testing every procedure on the users who’d eventually use our tech writing to ensure it would be read. Because of the demand for poundage, I learned to write fast; because of my own fastidiousness, I learned to write well.

Today, poundage is no longer demanded—in fact, the field has swung to the opposite extreme. The more concise the writing, the better the product in technical documentation. But more words or less, it always starts with a writer’s understanding of who he or she is writing for, and what that audience will need to know from the document to make it useful.

-Su

Over the last 30 years, the audience has changed as well. A few decades ago it was safe to assume that anyone working on a computer had a high level of literacy and ability to follow written instruction. Now there’s a strong chance that your audience doesn’t have English as its first language, and if the software design isn’t intuitive, you’re gonna lose your reader on the first nomenclature stumble.

Technical writing isn’t just about documenting software anymore. One of our favorite things to document at Precision Wordage is consumer electronics—anything from printers to big screen TVs. Over the years we have moved more into visual instruction, and stay away from excess verbiage whenever possible.

tell
For example, let’s take a mouse. This mouse happens to be wireless, which means it will need a battery. You could give the battery installation instructions as straight text:

1. Slide the battery cover away from the center of the mouse until it releases, then flip it open.
2. Insert the battery negative end first.
3. Close the cover.

Workable, but uninspired.

show
Or you could show it:

show and tell
Best of all possible worlds provides a balance of text and graphics:

In any kind of technical writing, the more you can show, the easier it is on your reader.

But technical publications still need to be produced. As long as products are going to market, the technical documentation has to be there on how to use them.

Some companies are turning to off-shoring, but, in the words of one former client who was forced by upper echelons to go that route, “It’s a challenge since English is not the first language of the writers… things … need to be sacrificed along the way.”

Is there another solution? You betcha.

On-shore outsourcing.

At Precision Wordage, we’ve been taking only outsource projects now for about 15 years. The projects we work on minimize client costs because the client pays only for the actual writing project (and gets a high quality product in the process). No overhead, no paid vacations, no severance packages when the project is over.

If your company is looking for ways to cut costs, consider using an outsource company. Crunch the numbers and you’ll discover that technical writing from an outsource vendor will deliver the most bang for the buck, especially if you can negotiate a flat bid or not-to-exceed deal.

And if the writer is American, chances are the technical communication will actually communicate.

- Su

Localization means adaptation of the language in a document or software to a new culture or region. This could be as simple as changing the spelling from British English to American English (for example, “colour” to “color”) or it could be much more complex.

Sometimes, when manuals are written in foreign languages (particularly East Asian languages) and translated to English, things are somewhat less than intelligible. And hijinks ensue. We writers affectionately refer to such abominations as “Engrish” or perhaps “Chinglish” in the case of a certain well-known language.

The problem arises when the translation is done by machine “translators” (which are mostly little more than word substituters) or persons who are barely literate in English. Underneath that, the quality of the original manual in the foreign language may not have been particularly good. The result is often a very confusing (and sometimes highly amusing) set of instructions.

“The luxuring wireless remote controlling stretches out and draws back the door” (translation: “Deluxe Wireless Remote Controlled Retractable Gate”) may be hilarious, but it doesn’t exactly put across the right concept.

But what does one do about it?

That’s where competent tech writers come in. We can take the most garbled manual and turn it into a sparkling jewel of clarity and usefulness. A good tech writer has a “knack” for deciphering what the original-language writer was trying to say, however goofy the translation, and re-expressing it in English that can be understood.

- David

In today’s fast-paced information age, we rarely have the luxury of hands-on instruction. In fact, technologies change so fast, and the amount of technology needed to survive in this society expands so rapidly, that one-on-one learning has become nonviable.

So how do we keep on top of these shifting technologies? And how do we make it possible for others to follow at a speed that makes production practical?

Through documentation.

Information is gold. Badly written information is lead. Accurate data clearly presented drives sales, reduces support, increases employee efficiency, opens new opportunities.

Technologies are lost only when they are not clearly and effectively communicated. Products are under- or incorrectly utilized only when the user does not have quick access to easy-to-follow procedures.

Investing in documentation is the way to ensure that your product or activities actually do survive into the future.

Get your technology documented.

- Su

The idea is to have a common set of rules that can be used across different documents.

And why would we want this?

Most businesses have a corporate image. This can include one or more logos, specific colors and specific type faces. As part of a company’s brand recognition, using templates in your documents allows for a continuity of image throughout all publications.

Another reason is speed. With a well-designed template, a document can be formatted to top-quality professional appearance quickly and easily. If every document published had to be formatted manually to match a common style, publishing costs would go up faster than the price of real estate in SoCal.

The process is simple: A document is either created directly from within a template, in which case the correct formatting can be applied as it is authored; or the document, already authored, has the template attributes applied to it.

Updates or refinements to your brand image are also easy to make with a template (another cost savings). Instead of making changes to every document, you can change the template and let the changes cascade through your documents automatically.

Invest in good template design for your publications department, whether you use Microsoft® Word, Adobe® FrameMaker®, Adobe InDesign®, or any other publishing tools, and ensure that your templates include instructions on how to use them!
The problems our clients can create for themselves when they don’t use templates range from comic to incredibly expensive, but that’s another blog on another day.

- David

At Precision Wordage, we follow the rule “two sets of eyes, minimum.” No matter how good the writer, no matter how clean a draft, whether you write it or we do, an author cannot proof his own work.

What skill set does it take to do a good proof job?

The most vital skill is the ability to spell. Spell checkers can catch flagrant misspellings, but won’t catch those nasty homonymic errors. “He road the hoarse across the open rode, ignoring his horse cough.” You see what I mean.

The next skill is grammar. When I was a kid, I used to diagram sentences for fun. It came as a shock to discover that diagramming hasn’t been taught for decades. Makes me feel old. The PWI team knows their syntax (the rules for forming words into correct sentences) cold.

Then there’s style. The basic bible for publishing is The Chicago Manual of Style. But then there’s the Microsoft Manual of Style for Technical Writing, and who knows how many other upstart new publications to cover the morass of media rules, regs, recks and refusals on grammar relating to technology, not to mention classics like Strunk and White’s Elements of Style. Our guys know `em all. And then some.

A proofer has to be able to think. For example, we deal with a lot of new technology, with scores of words that didn’t exist twenty years ago. If the proofer hits a term that’s spelled inconsistently in a client’s document, he’ll go online and search until he finds the most common usage, and recommend that the client use it that way. And he’ll stick it in the style notes for the job. If the client wants to spell a word differently, that’ll go in the style notes as well. And the proofer will know that with client A he always uses “dingles,” but client B expects “Dingles” to always be capitalized.

In proofreading, like most things in life, there are no absolutes. But we come close when it comes to catching those pesky little errors that detract from a document’s polish.

- Su