Uppercase this!

November 20, 2008

One thing that irks me about some subject matter experts is that they love to capitalize words that are near and dear to their hearts.

Accountants explain that Vendors must include a Purchase Order number on the package or the Invoice will not be paid.

Energy industry professionals tell us that Natural Gas and Crude Oil are important fuels.

Lawyers put it over the top by including terms in quotation marks and parentheses:
Our Company (“Company”) will lobby Members of Congress (“Members”) this month.

Bill Walsh wrote cleverly about this annoying problem of arbitrary capitalization.


Becoming better designers

November 14, 2008

Recently a coworker asked me to help him fix a complex Word document containing important information for our company’s operations.

“Whenever we try to update this document, the numbering sequence goes out of whack,” he said. “Can you help? Also, it doesn’t look as good as the stuff your group produces, so anything you can do to improve it would be great. ”

I agreed to help out and before I could say, “white space,” was plunged into the fourth dimension of tech comm — document design.
Document design is probably the least discussed area of technical communication, yet it’s the one where most of us require the most assistance.

Early technical writers didn’t have this problem. They wrote their copy on a typewriter and turned it over to a typesetter.

With the advent of desktop computing, typesetting and document design was transferred to the technical writer — ready or not!

Of course, technical communicators at large companies have the advantage of a design department that sets the standards, ensures proper branding, and may even provide assistance template design. But lone writers and those of us in small or dispersed groups must tackle design on our own.

Therein lies the problem. Most of us who stumbled into this profession are either writers who enjoy technology or technology people who enjoy writing. But we are not designers. Information design (a fancy name for technical communication) does not equal document design.

We can deftly chunk information; put it in the proper order; quickly distinguish between reference info and procedural tasks; apply minimalism in our narrative; and index thoroughly and thoughtfully. But if we neglect our fonts, styles, alignment, format, illustrations, headers, footers, and callouts, our audience struggles to absorb the content.

Every technical writer I’ve met is an autodidact when it comes to document design, but we manage to pull it off because our managers and many of our customers know less about design than we do. This means that even a meager attempt to employ basic design principles results in a WAY better document than most people can muster.

Problems arise when several self-taugh tech writers in the same department are challenged to agree on best practices for designing their templates. Fierce debates are likely to ensue because no one has enough authority on the subject. I myself am a scarred veteran of such battles including the hard-fought “Defense of the Round Bullet,” which I won and the “Campaign to Adopt Arial Narrow,” which I opposed and lost.

For this reason at STC conferences, sessions on document design (and they are few and far between) are mobbed, because we are hungry for more information — and secretly hoping we can return home with more ammunition for the next design skirmish.

I’m happy to say I was able to utterly transform the ugly document presented to me by my coworker. It was greeted with joy and praises at a subsequent meeting of employees who use the document regularly.

Here are my primary sources of information:

Jean-luc Dumont
We had the honor of hosting Jean-luc at our Currents conference this year.

You can read his papers on his Web site, but you really need to experience him in person. He engages all the participants in the discussion and instead of lecturing at you, draws you into solving design questions. You walk away with some simple, but profound principles that will serve you well in any design dilemma.

Karen A. Schriver’s Dynamics of Document Design.
I’m rediscovering this book after reading (some of) it ten years ago. Schriver shares some interesting insights her team gained while researching document design. She also has a wonderful timeline showing milestones in document design over several decades and how they relate to other historical events.

Robin Williams’s Non-Designers Design Book,  and The PC is Not a Typewriter. No, the famous comedian did not write these books. Robin (female)  is a graphic designer who lives in Santa Fe, New Mexico.

I’ll write more on this soon.

How did you learn about document design?

How’s the job market?

November 4, 2008

Despite the problems in the economy, I’m not seeing big layoffs in our profession yet.

(I probably just jinxed myself with that statement.)

The Center for Disease Control is hiring a Technical Writing Editor. Check out the bureaucratic hoops you have to jump through for that position. 

Oracle also is advertising an open position

Most of the other job postings I saw were contract positions, including a couple at ProEdit. If you’re willing to relocate to Huntsville, Alabama, they do have “permanent” job there. 

Mike Hughes had some good advice on getting through the recession. 

I think flexibility is another good strategy in this market. Draw on all your experience and use it sell your versatility. An STC member I know, for example, just got hired at my company as a Business Analyst. 

This month’s Atlanta STC program explains how to write federal proposals. A good tech writer should be able to make that transition easily. It’s structured writing, with its own terminology, tight deadlines, a collaborative effort that has to be managed like a project. Sound familiar? 

Remember, this month’s meeting is at Southern Poly State U.