Last night, I attended our monthly STC Intermountain Chapter meeting. Bob Lindsay, an e-learning developer and manager, presented some tips on writing for e-learning modules.

Some of his tips regarded how to reduce necessary maintenance on your modules. The bottom line in this part of the presentation was to keep things generic when possible so that, later, there is less to have to change when the product changes.

Bob invited questions and discussion, and my manager, Kurt, made a comment about being a detail-oriented writer. He thought that avoiding specifics goes against his objectives. I have to agree on that. Bob’s tips were mostly small things you can do that will save you time later and would probably not impact your deliverables in a dramatic way; but in a larger sense, ease of use butts heads with ease of maintenance.

(more…)

A little while back, Michael emailed me an invitation to look at some findings from a study about online experience. I haven’t had a chance to check out the full document yet, but the executive summary contains quite a bit of information. I’ll consider here how some of the findings affect technical documentation.

Easy Access to Complete Information

One point made in the findings is that users’ “enjoyment” of a site is tied closely to how easily they can find the information they want and stay oriented at the same time. I think this is a given for technical communicators; we know that users want to get answers as fast as possible, and documentation must be navigable. Those two factors are easier to pin down than a third: “complete information.”

(more…)

I needed to come up with a way recently to put some Captivate demos in a place where stakeholders could review them for accuracy, without putting them out somewhere on my domain where anyone could stumble on them during the review process. For a few moments, I thought of simply putting up some password-protected WordPress pages. But then I realized (an instant before Tom Johnson suggested it to me) that I could use SharePoint.

With a few clicks, I created a site and was off and running.

(more…)

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.

(more…)

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?