Networking was a big emphasis when I was getting my technical communication degree. More than any of the other emphases within the English degree, the tech writing emphasis was geared toward preparing its students for entering the field. For technical communicators as much as many other professions, networking is an important factor in getting a job. With social networking sites, a new dimension of networking emerged.

When I had only a couple of months left in my internship at my church’s headquarters, the business analyst who had hired me extended an electronic invitation to join his network on LinkedIn. Because my future was uncertain and I needed as many ways to develop a network as possible, I created a profile.

I found out that many coworkers also had LinkedIn profiles. I connected with those I knew well, and I have tried to keep to that practice. The idea I get from the site is that its purpose is to connect people who have worked well enough with each other to be able to recommend each other to potential employers. Some people, however, seem to jump at any chance to build their networks.

Read the rest of this entry »

I’ve been a feedreader and blog hermit lately because I’ve been working on a couple of projects in my spare time. I’ve still shown my face (did I just hear a shriek…?) in the RoboHelp forums, mostly because it’s not a big time commitment. Get an email, go to the forum, give a reply, get on with life.

After a recent round of WebEx training on a Web application, one of our stakeholders proposed a different scheme for training. This application is going to go out to far-flung offices, and we see the potential for spending a lot of time training the staff. In addition, we tend to discuss peripheral issues and edge cases more than we should, lengthening our sessions.

The new scheme is to provide some quick-start material directed to the office staff roles. Then we’ll provide a menu of demonstrations done in Captivate. The demos will cover the “happy path,” as one of the managers calls it, rather than wandering off the main road into the dark woods and fields of tangentia (I think I just made that word up). Support for edge cases can come from the managing offices.

Next, we hold question-and-answer sessions by WebEx.

Finally, the stakeholder department will provide coaching and support.

I think this is a good approach for this particular situation. Quick-start guides or quick-reference cards may become a standard part of our deliverables. I and the designer on this project are going to propose a training page that is reachable from the landing page. The Captivate demos would open in modal windows. We have to pass it off through the project management, but I think with this new emphasis on training, this page will be added in.

To me, that’s one benefit of Agile development. If needs come up during a project, as long as there’s room in the budget, you meet those needs. We’ve seen a training need appear, and so we take care of it rather than ignoring it because it wasn’t in the original specifications or plan.

Right now, our team provides a selection of documentation deliverables to stakeholders. We have quite a list: online help (context sensitive or otherwise), quick-reference guides, animated demos, tutorials, manuals, and so on. In my opinion, documentation is not a once-size-fits-all matter.

However, the idea is to give the stakeholders guidance on what is appropriate for a particular project rather than letting them just pick and choose what they like. For example, as one project was being planned, I met with some of the project leadership and the main stakeholder, and at first the stakeholder wanted the same documentation products that we’d had in another project we did for him. This project was much less extensive and complicated, so I talked him down to something less grand.

Do you have a standard set of deliverables for the products you document (or manage), or do you offer a selection?

I received an email yesterday through a listserv that jerked me awake. In a discussion about which is more important when looking for a job, the skills or the tools, one person’s point in particular stood out to me. The respondent said that when you put the emphasis on tools and not skills, you get people who take a class on RoboHelp, for instance, and call themselves online help developers.

She said that she worked with such a person, and among the problems with this person’s products were “topics that require massive scrolling.”

Put me in the lineup, officer.

Okay, so I maybe I haven’t gone to the extent of committing a crime. But this comment directed my attention to a couple of topics in one of my help projects, and I set about fixing the problem immediately.

Read the rest of this entry »

On a day that is infamous to Americans, let us pay tribute to those who have lost their lives in order that we can remember the privileges that are ours.

Let us realize that it shouldn’t take a terrorist attack for us to feel united and to be united.

Let us look back and see how easy it can be within a matter of a few years to forget those things that should have changed us for the better.

Let us then remember and change.

May those who have given up time, safety, strength, limb, and life be honored on earth and in heaven for their sacrifices for their fellow beings.

May those who have lost their lives in defense of the United States of America and the freedom of the world’s peoples be borne to God as on eagles’ wings.

A few months ago I posted seven reasons an organization needs technical communicators. This week, a program manager I work with provided a few more ways that technical writers provide value to organizations and projects, so I wanted to pass along his wisdom—with my own discussion, of course. Because I gave seven reasons before, I’ll start with number eight.

Read the rest of this entry »

A while back I started thinking as a writer about the fact that programmers “write” code. I came up with more differences than similarities between the writing a programmer does and the writing I do as a technical communicator.

A programmer has to follow very specific, strict rules when writing code. If he doesn’t follow those rules, his “writing” isn’t going to be interpreted correctly. When that happens, things break. But that’s because it’s a computer that has to do the interpreting.

To some degree, a writer has rules to follow—they’re called spelling and grammar. (There’s a reason that code structure is referred to as syntax.) If those rules are flagrantly broken, you may have a similar problem to bad code; the recipient interprets incorrectly or doesn’t know how to interpret it at all.

However, writers have some leeway. Readers aren’t as strict as computers. They can infer meaning even if the rules aren’t followed to the letter. Writers also have freedom in vocabulary, but programmers can’t substitute established jargon in their code without breaking it.

I’m sure it is these differences that draw some people toward programming—they like the hard and fast rules that avoid guesswork—and pull others toward real writing. I like to do some coding, but it’s playing with language and words that interests me in writing. I like the freedom, not a computer telling me how to write.

And that’s the reason I have grammar check permanently turned off.