At the STC Summit, Tom Johnson and I gave a presentation entitled “Quick Reference Guides: Short and Sweet Technical Documentation.” Frankly, I was kind of proud of that title because it just fit within the eight-word limit.

Like usual when I’m speaking in public, I was nervous beforehand, my mouth went dry within the first few minutes, and after that I was fine.

Overall, comments were good. Someone went as far as to say that our presentation gave him the most specific information in the three years he’s attended the Summit. We had a full room, and three people watched from the hall. On the other hand, an anonymous (according to Tom) person tweeted that our presentation was more frustrating than interesting and lacked a moderator and concreteness. I’m not sure why the person chose to be anonymous; I hope it wasn’t a fear of some kind of backlash. Tom and I aren’t going to turn around and send hate-tweets.

It was a good experience, but after something like that, I feel like not presenting for the next five years. It’s a lot of buildup to that one hour, and then afterward I second-guess my performance. As Tom pointed out as we discussed it later, that piece of negative feedback did make us think about how to do better. If the world had no naysayers or detractors, maybe we’d have less motivation to improve things.

› Continue reading…

Bookmark It

Hide Sites

If you asked someone to name a group of people who are passionate, the first answer probably wouldn’t be “Technical communicators.”

We’re classed, to some degree incorrectly, as introverts and nerds. In this respect, we’re judged similarly to software developers. As someone joked in an STC Summit presentation, “What’s the difference between an introverted engineer and an extroverted one? The introverted engineer looks at his shoes when he’s talking to you; the extroverted one looks at your shoes.”

Introverted people aren’t normally considered passionate.

Even if you’re an extrovert, would you consider yourself passionate about technical communication?

Being passionate about your work has a couple of benefits. One, you enjoy your work, and it doesn’t feel so much like work. Second, passion demonstrates that what you do is important to you. If you don’t convey that your own job is important to you, then others will have a harder time considering it important.

› Continue reading…

Bookmark It

Hide Sites

Last year, I came to the Society for Technical Communication Summit as a first-timer. This time, i came as recently elected Intermountain Chapter president.

Actually, I found out from our webmaster here at the Summit what the results were. No one ran against me, so I was pretty sure of the results, but I didn’t want to make assumptions.

For me, the Summit was an overall positive experience because I learned things that I can take back to my local chapter and use to boost activity—or at least to get some attempts going. I attended much of Leadership Day and the annual business meeting, which got me thinking about what the chapter can do to help members who may not have renewed membership due to unemployment. STC has experienced a substantial shortfall this year, just as many other associations have been severely impacted by the state of the economy. I found myself discussing opinions with other chapter officers.

Leadership Day ended and the main program of the conference began with the opening general session and a keynote by Shawn Henry, an accessibility advocate and member of the W3C’s Accessibility Initiative. Her main point was not just that we should make our products accessible to those with disabilities, but that when we do it, we benefit all users and can even develop better ways of doing things in general.

› Continue reading…

Bookmark It

Hide Sites

Because I work on a family of applications that are being developed to replace a legacy program, sometimes my work of documentation and training directly supports the transition from legacy to new. Part of the development team’s replacing and enhancing the legacy functionality is providing a series of reports on data in the systems.

One of my assignments is to provide some documentation that will tell the users how to use the new report prompts and parameters to obtain certain result sets that they have gotten with the legacy reports. My concern with this request is that it is essentially throw-away documentation. Other material I’ve created that relates to this transition period has been around for months and even years now. But we’re getting close enough to turning off the legacy system that I hesitated to produce documentation with a life of only a few months.

› Continue reading…

Bookmark It

Hide Sites

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?

Bookmark It

Hide Sites

Last week’s STC Summit in Philadelphia was the first society-wide conference I’ve attended. I looked forward to the conference as an opportunity to learn to improve my technical writing and find out how the technical communication profession is taking advantage of Web 2.0.

Here are some positives and negatives from my experience at the summit.

› Continue reading…

Bookmark It

Hide Sites

Now that the STC Summit is over, the session that sticks out in my mind the most is Ginny Redish’s one on “writing as an asynchronous conversation.” I don’t think I had heard of Ginny before the conference, even though apparently she’s about as famous as you can get in the technical communication field. But once the session was over, I could see why she had reached that level.

In one hour, Ginny gave the audience a clear understanding of the topic and how it applies to everyday work. That’s one of the things I really wanted out of the conference: some specific ways of looking at my writing and seeing how it can improve, or specific devices for better instructional content.

› Continue reading…

Bookmark It

Hide Sites

One of the topics the panel addressed—however briefly—in the opening session of the 2008 Summit of the Society for Technical Communication (STC) was the need for us to have user participation in and feedback on our content. This was of interest because our team at work has been looking into doing this.

The irony of the situation lay in the fact that adjacent to the hall where this session was held, a number of vendors were waiting to catch society members’ interest and corporate dollars. In his presentation on using user-generated content in documentation, Scott Abel of The Content Wrangler referred to the lack of Web 2.0 software. An STC member I talked to on Monday after one of the education sessions said that she had asked one of the Adobe Systems representatives about Web 2.0 capabilities in technical communication software.

“We don’t do that yet,” the representative told her.

Fundamental problem.

Personally, due to my current experience using WordPress to blog, I’ve been exploring the possibility of using it to provide a help community for the projects I work on. Because it’s a blogging platform, conversation is part of its definition.

Right now, the big push—and therefore the big race among vendors—is single sourcing and structured content. That’s what they’re providing, but that’s only part of the puzzle at this point.

If STC has any clout, I would like to see it influence the tech comm software companies to provide us easy ways to encourage, receive, and store user feedback and contributions. Right now, we have to resort to JavaScript-driven links or forms to get feedback. I see it on the RoboHelp forums: If someone decides halfway into a 5,000-topic project to incorporate something like this, he’s got to use a find and replace tool or—some of us have resorted to this—manually going through each topic and pasting the chunk of code in the code view of each topic. Not all technical communicators are members of STC, but the society could advocate for the profession at large for this kind of software.

Our software has to make it easy for us to do what we’re being called upon to do in our profession. It doesn’t matter if all the software suites provide it, as long as the ability is there so we can make use of it. If they don’t provide it, our organizations may have to keep our money and choose tools that are both free and accommodating.

Bookmark It

Hide Sites

In the opening meeting of the 2008 Society for Technical Communication (STC) Summit in Philadelphia, several members of the society participated in a panel discussion moderated by Paula Berger. They spent most of the discussion talking about how the technical communicator needs to convince management that she solves business problems—specifically communication problems.

I agree that technical communicators need to provide value. Anyone in any job needs to provide value, or there’s no reason to keep you there taking up space and expending resources. But if you’re valuable, management will want you to stay. Let me illustrate.

› Continue reading…

Bookmark It

Hide Sites

A graduating university student’s recent email to the STC Instructional Design special interest group listserv reminded me that it’s the time of year when focus and hard work can give way to the stress of the job search. Having been in that position myself not many years ago, I remember wanting any advice that would give me an edge in breaking into the technical communication world and bringing in a steady paycheck.

In the spirit of wanting to turn around and help those who are in a position I was once in myself, here are some guidelines that I hope help you get that job. (Since many students are graduating within the next three weeks, it may be too late for some of this advice, so I’m directing my counsel toward any university or college students looking to get into tech writing.)

Today’s post focuses on building your educational experience.

› Continue reading…

Bookmark It

Hide Sites