Alert: Grammar complaint. Don’t worry, it’s not my intent to figuratively bludgeon you with a textbook or rap your knuckles with a yardstick.

Due to a push for gender equality, the pronoun “he”—and its brothers, “his” and “him”—are rarely accepted anymore as talking about an unidentified person. That’s fine; I don’t have as much of a problem with that. It’s the fact that since in English we don’t have a neutral singular pronoun, people instead have introduced “they,” “their,” and “them” as the substitute to avoid the clunky “he or she.”

The cure is worse than the disease.

Take this line from a recent email:

“Do a Colleague a Favor, Invite Them to Join STC.”

Read the rest of this entry »

The other day, I spent a few minutes in a project planning meeting to give an estimate for the time it would take to add to an existing help project for phase two of a software application. The dev lead, going for a joke at the expense of two of us, said, “Of course, I like to tell the interaction designers that if they’re doing their job, the app doesn’t need help.”

“I’ve heard something like that before,” I said.

The interaction designer looked at me and replied, “Well, I like to tell the developers that if they did their job, we wouldn’t need QA.”

Nice.

I think the QA lead was the only one who wasn’t laughing.

The other day, I was talking to one of the interaction designers I work with, and he mentioned something that brought a little shame upon me. He had been talking to one of the application’s users when she pulled out a manual for the legacy application—contained in a binder, I think—and it had loads of handwritten notes in it. I realized that I had ignored one of my own suggestions when dealing with legacy apps. I had not looked at, let alone leveraged, any legacy documentation.

This is a fairly small project and is phase one of two. The user base isn’t large. When I started on the project, I figured I would just document the new system. Much of the work I’ve done over the last few years has to do with applications that replace legacy systems, and I think this time I may have just overlooked the legacy documentation because of the project’s relatively small size.

Even if I don’t end up using any of the legacy content, it’s a valuable exercise to see what’s there, what the users have been making use of. It’s even better to see what notes they’ve been writing in the margins so I know what kinds of information they find important.

The designer will send me the electronic copy of the old manual, which will be a good start. Next will be a trip to the users’ desks to see their own additions, perhaps what you could call the original wiki. Phase one of the project is nearly over, but I’ll have phase two in which to make any adjustments based on what I find out. It’s been a good reminder of what I ought to be doing when documenting applications that are replacing legacy apps.

Recently I worked on a mission statement for our user education team because I’ve tackled that kind of thing before. We want something that we can measure ourselves against to see how we’re doing in our role. Our organization has its stated mission, and our department has a vision as given by our CIO.

In a department meeting yesterday, he demonstrated a project that’s in the works, and he showed us a “purpose statement” that goes along with the project’s rationale and background work. I think I like that wording better than “mission statement” because it gets closer to the heart of things. A purpose is at the root of a mission.

What’s in a mission statement? To me, the term “mission statement” carries connotations of inflated language and feel-good rhetoric. It belongs coupled with a scenic photograph in a frame. With this attitude, it’s hard to take it seriously when you task yourself (or someone else tasks you) with writing one. We did some brainstorming as a team about what our purposes and aims are, and then I took the results and took a first shot at putting them together.

Read the rest of this entry »

Last night, Tom Johnson led a meeting of the STC Intermountain Chapter. The format was an informal discussion between chapter members as we took turns talking about what challenges we’re facing right now. I thought it was a very productive evening for those of us who attended. We talked about following that format more often because of the direct impact on what we’re doing professionally and the difficulty of getting speakers for every meeting.

Tom was making a comment at one point, and he said, “I don’t know about anybody else, but I’m a perfectionist.”

Paul Pehrson said, “Isn’t that why we’re in this profession?”

I had thought I was the only one.

Maybe “technical communicator” is synonymous with “perfectionist” after all. I can see the position of quality assurance engineer as enticing to perfectionists, but sometimes things that bother me don’t bother them (consistent capitalization, anyone?). What is it about tech comm that draws perfectionists?

Someone who wants to make sure everything is done right wants proper documentation in place for a project. She understands that an application isn’t complete if the users aren’t educated about how to use it. Documentation and training is seen by some as a detail, but part of perfectionism is attention to detail. Also, while we’re documenting processes and products, we’re always asking “What about this? What happens if…? What happens next?” We tell users the best way, the right way to do things.

So I think Tom and Paul were pretty accurate. Being a perfectionist can be stressful because no matter the current status, it’s not good enough. It feels like we need a support group sometimes. Maybe our STC chapter meetings should start with each person standing up and saying, “Hi, my name is George (or Jack or Flo), and I’m a perfectionist.” And everyone will nod because we all understand George (or Jack or Flo).

We understand that we’re not perfect, but we want the world we live in to be a perfect place. And it can’t be perfect without a few perfectionists writing documentation. Otherwise, how will everyone else know the right way to do things?

The prevailing perception of printed documentation is that it’s a goner. Because of the work I’ve been doing on quick reference guides lately, I disagree; I think people don’t necessarily want everything online, but at the same time they just don’t want a thick manual they’d sooner use as a booster seat for their toddlers at the dinner table.

Read the rest of this entry »

One of the things my last post made me think about was a benefit of having a technical communicator involved in the design stages of a product. If the designer involves the writer during the design phase, the latter can look at the design with the question, “How will I explain this? Will this be reasonably simple to explain?”

If the answer to the second question is no, then that’s feedback for the designer. And it’s early enough that the cost is lower. The ship hasn’t left port yet, so you can adjust your coordinates while it’s still easy to do so.

Read the rest of this entry »