Currently, two main things bother me with my approach to help, and I’m looking for a way to solve these problems.

Problem 1: I Can’t Update Help on the Fly

Like the application code that I document, my materials are checked by the testing team. I don’t have any problem at all with that; in fact, I think it’s a benefit to my deliverables. Some sharp-eyed testers have caught errors, and because they’re also testing the system, they can verify that my descriptions of the system are accurate.

We also have a change control process for production releases. Right now, in two of the three projects I work on, my help is rolled up in the builds and launches because I commit my help into the Subversion repository where the Java code goes. This causes my help to appear in every environment, and I like that it is swept up in the launch, and it’s included in the change control approval. But this also limits me to deploying help only when the applications are launched, unless I want to go through a separate change control process.

Fortunately, if I can make a case for deploying help outside this process, I believe things will be negotiable.

Problem 2: No User Participation

Right now, help authoring tools don’t provide out-of-the-box ways for us to have conversations with our users. I would like to have user feedback directly on my help—something of a Web 2.0 component. I want users to be able to comment on help topics, and I want to post updates and tips (this part goes back to the inability to update on the fly). I never have any idea how helpful my help really is. How many times have you looked at help just because you’re a technical communicator, and you had feedback for the nameless and faceless writer? If you had a comment box and button, you may have fired off a suggestion right then, but chances are, no such mechanism was available. I want to give users that chance so that I can turn around and improve the content.

I’m enough of a control freak just yet that I’d prefer to police the editing myself rather than having a wiki. I heard recently that some study found that if there are punctuation or grammar mistakes in wikis, it’s more credible because the readers think it was written by a real person. (Didn’t you know that as a technical communicator, you’re a robot?) I argue that for every person who finds this type of unpolished material more credible, there’s another person who thinks it’s garbage because of the errors.

A Potential Solution

So since I blog with WordPress, it waved its arms and legs at me like the basketball player who’s always open. I understand that WordPress can be used as a content management system, so I figure, what the heck? Let’s give it a try and see how well it works.

One strength is the number of plugins available. If you know the basics of CSS, you can also customize the look and feel of your site to match the product you’re documenting (especially if, like me, you document software).

However, one possible limitation is how well WordPress will allow me to accommodate different user roles. Right now, I use RoboHelp’s conditional build tags to create different outputs addressed to different users from the same topics.

The only thing is to jump in and see how well it works. The point is for me to see what I can do to alleviate the problems I’m facing at the moment. It just seems like what I really need isn’t out there right now. I’ll keep you posted—no pun intended.