What I learned about our profession while creating a Tech Comm Jeopardy game

December 12, 2008

Whew! Long title for this post. 

Alternative (but not necessarily shorter) titles I considered:
“What is the question to which Technical Communication is the answer?”
“There are no facts in this field” 
“Technical communication is an art, not a science” 

jeopardy1Here’s the back story:
For the last three years I’ve volunteered to organize our Atlanta STC chapter holiday party. 
I like to plan a couple of games to make it fun and to prevent it from degenerating into a pure drinking activity. (I can hear some of you saying “What’s wrong with that?” but I’m ignoring you.)

Last year I created a simple Jeopardy game around the theme of Atlanta since that’s where we are and that’s where the STC Summit will be this year. I don’t know Flash, so I did a down and dirty, yet still electronic game using Word. (More on that later.) Using Wikipedia and my husband’s encyclopedic knowledge of the city, it was easy to create categories and questions (or in the case of Jeopardy — answers). 

This year, I announced we’d have a “Tech Comm Jeopardy” game at the party. I quickly amended that to an “Atlanta/Tech Comm”  theme, because I couldn’t come up with enough solid FACTS about our profession to populate an entire game. Sure, you can come up with “insider” questions about personalities in the field and software trivia. But name one universal truth in our profession that can be summed up in the Jeopardy format. 

“Know your audience.” Yeah, OK. But what is the answer to which “Know your audience” is the question? You see where I’m going with this? There aren’t even, to my knowledge, “schools of thought” in our profession that can be referenced such as “Maslow’s hierarchy of needs” or “Garner’s Multiple Intelligences.” The best I could do in the theoretical realm was a question/answer on “information mapping” for Pete’s sake. Did I just use “theoretical” and “information mapping” in the same sentence?

I challenge you, my readers, to tell me what are the Truths (and here I capitalize intentionally despite my disparaging remarks on this subject in the last post) of our profession? There are many word of wisdom out there, but can they be distilled down to a Jeopardy question? I say NO. 

Should we be concerned about this? 

PS.

If anyone is interested in how I created the Jeopardy game in Word, let me know and I’ll send you the file. I just created a table and then layered shapes on top of each cell with the “answer” and the dollar value.  

As it turned out, I was unable to attend the holiday party this year. I’m dying to hear if the handful of Truths that I inserted into the game were acknowledged or widely debated and bashed. The party should be breaking up just about now. So if anyone sees nerdy people fighting in the streets near Holcomb Bridge Road, tell them to sober up, go home, and read my blog.


The well-dressed technical writer

December 3, 2008

Appropriate attire for the IT holiday luncheon.
(remember to add shoes before leaving the cubicle or office)

Only get to wear these once a year.

Only get to wear these once a year.


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.
grid
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.


A typical day

October 29, 2008

The prolific Susan Wu described her “Typical Day as a Technical Writer” last March. At the risk of boring you to death, I will do the same here. 

8:24 am
Pat dogs, kiss husband, and leave home for work. Listen to Schulz and Peanuts: A Biography on CD in the car. Tears come to my eyes when Schulz’s mother says to Charles as she is dying of cancer, “If we get another dog, let’s call him Snoopy.” What a way to start the day. 

8:45 am
Arrive at work and boot up computer knowing it will take at least 15 minutes before I can read e-mail. Brings to mind the article in Sunday’s New York Times about this universal annoyance. Researchers are working on a cure. 
Two of the four writers on my team will be in the office today. The other two work for other clients on Tuesdays. 
Grab a cup of tea in the kitchen. For the second day in a row I find free cupcakes on the counter. Can I resist? 

9:00 am 
Head down to CIO’s office with my director and the other manager in my group. This is a weekly meeting where we report on what we’re doing. Currently I have about 10 separate projects creating user guides, online Help, training materials, and training content. The other manager is in charge of records management and has even more projects underway. As the meeting wraps up we lament our diminishing 401Ks and our increasing years until retirement.

On the way back to my office I run into a friend from our California office who is in town for meetings this week. We went through some hectic times last year on another project so it’s great to see her again. 

10:00 am
Read, answer e-mail, and listen to voice mail, rewrite my to-do list.

Unsubscribe from three lists I never signed up for. My title is Manager, Technical Communications and lots of people think I’m in Telecommunications. Further evidence that everyone just skims instead of reading today.
Howard from Atlanta STC asks if I’ve reserved a room for the November Council meeting. I confirm.  

Another former co-worker has asked to link up with me on LinkedIn. I accept. Hurray, I’m have over 200 connections now. 

10:30 am   
Call internal customer who needs our help writing a brief user guide and back-end manual. Discuss deadlines, who will be single point of contact, etc. Call writer to ask if she has bandwidth to take this on. She does not. Consider who else to assign to this job. 

Another manager on my floor pops his head in the door to say that I have to move my contractor who is squatting in one of “his” cubes. Luckily, there is another vacant cube for him to move. Otherwise, he’s condemned to the cramped “bull pen.” I dutifully submit a move request and inform the employee. He’s cool with it. 

11:00 am  
Receive a draft of a user guide from one of my off-site writers. Begin editing. 

Phone rings. Someone from Legal needs another online course set up ASAP. I promise the world and then look at my list of projects and my calendar to see how I can deliver. 

Manager of contracting firm e-mails to ask how his employee is doing. I send back a glowing report. 

11:30 am
We are preparing to deliver an instructor-led course to employees on Word 2007. I’m reviewing the outline we created and thinking about useful exercises. 

12:00 pm   
Lunch bell rings (in my head).
I decide to do something I’ve been thinking about for several days. Next door they are building a mixed-use development. Today it’s just a big hole with a big pile of dirt next to it. I go to the top of the parking deck and take a picture. Resolve to take one picture each day until the structure is built. Then I’ll put it on YouTube (or something).  What the hell, I’ll get some exercise walking to the 8th floor and back each day.

Grab a salad at the cafeteria in the next building. While I’m eating, check out Twitter.

12:30 pm   
Write short set of instructions needed to update our timekeeping manual and online Help. Determine appropriate environment (dev, UA, QA, or TRAIN) to capture screenshots, which user to represent, dates to choose, etc. 

Finish editing the document I began this morning and send to writer. 

2:00 pm
Daily meeting for one of my key projects. It’s not an Agile project, but sometimes it feels that way. 

2:15 pm   
Finalize travel plans for trip to NY plant in early December.  Answer more e-mail and go in search of answers to other queries. 

3:00 pm
Weekly one-on-one with most senior (in years, not age) employee. She is wearing several hats and overworked, too. I offer help, consolation, cheap advice. We agree to a cram session on the Word classes in late December when most people are out of the office.  

3:45 pm
Husband calls to say he’s taking the dogs to walk on the river. Would I leave early to join them? I sigh and decline. Confirm that we’ll have salmon for dinner and green peas. Check out the stock market while I’m talking to him. The Dow is up!!

4:00 pm
Go to the kitchen to wash out my tea mug and notice that two of the six Halloween cupcakes are still on the counter. Take deep breath and return to desk sans cupcake.  

4:05 pm
Call contact in Accounting who promised to deliver training content to us today. She confirms she will send it today.
Stop by “hotel cube” where my friend from California is catching up on e-mail. We talk about pets, holidays, travel. She has dinner plans with other out-of-towners who are here for the big Operations meeting tomorrow.

4:20 pm
Return to office to see that Accounting training file is in my Inbox. Grab another cup of tea and begin reviewing. What kind of graphics can we use for this stuff? 

5:00 pm
Another look at e-mail. Ann from the STC Management SIG promises to get the candidate bios to me soon. Someone sends me a job opening for a tech writer. I forward it to several people.  

Open folder where I send all e-mails for top project. Click through to see if anything is relevant to me. Nada. Delete all. 

Another e-mail from the same project pops in with question: “User wants to know what reports are available to her in the application.” I write back, “See the online Help for details on all available reports.” I suppose it never occurred to them to check the Help. Bleeaaah!

Review schedule for tomorrow. Review what I didn’t do on my to-do list. Add a few more things I forgot about.  

Check out my sister’s blog. She’s in Japan visiting her daughter who’s teaching English north of Tokyo

6:00 pm
Pack up and leave. Nearly collide with one of the company’s head honchos on my way out of parking ramp. Rats.  

6:30 pm
Home!


Time to stop blogging?

October 21, 2008

Yes, it’s been a while since I last checked in.

This article from Wired magazine struck a familiar chord, but it doesn’t completely describe my funk. It points out that Facebook, Flikr, and Twitter are becoming the preferred social networking channels for individuals. I’m not blogging, but it’s not because I’m Twittering, Flikring, or Facebooking instead.

The article also says that today, it’s almost impossible for a single individual to be a big-time blogger. But that was never my goal in the first place and still isn’t.

Technical communication is and will always be a small niche in the blogosphere. Since we are writers by profession, more and more of us have started blogs. I’ve been reading some of them and they are pretty good. I slowed down partly because I didn’t think I had much to contribute to the conversation.

But the blogging conversation is different than a conversation at a dinner party or even on a listserve. In those situations if someone says, “Consider the oyster,” and you just happened to also be contemplating oysters, you would look foolishing saying, “I want to talk about oysters.”

In the blogosphere—even the narrow tech comm corner of the blogosphere—there is room for two, or even five or ten simultaneous oyster diatribes because we all have different audiences with some overlapping on the edges. If we are truly speaking in our own voice, we won’t be talking about oysters in exactly the same way. This may or may not be useful to our audience.

I began blogging as a way to reach out to the STC chapter in Atlanta when I was president two years ago. I had a lot of fun with it and decided to continue. I like to write and I like to share things I’ve learned or seen or thought about. Sometime over the summer I lost my inspiration. Then I felt guilty as each week passed without a blog post.

When I read the Wired article today I thought, “What the heck? There may not be any pearls inside this oyster, but I’m still swimming along in the STC/tech comm tide with some opinions, thoughts, and observations.” So I will chug along here at a relaxed pace for a bit longer even though it is so 2004.


Follow

Get every new post delivered to your Inbox.