When I was in elementary school, I learned that it’s pretty much guaranteed that when answering true-and-false questions, if the statement contains any absolutes, it’s false. Notice I hedged there a bit.

The same thing is true when we’re talking about tools and technology in technical communication.

I see blog or Twitter posts sometimes that insist that some approach is the key or the only way to go. Sometimes, such statements are true—if they support such timeless principles as knowing your audience. But when they set forth some technology or technology-based approach to communication as the silver bullet that will solve all your tech-doc woes, I don’t buy it.

› Continue reading…

Bookmark It

Hide Sites

I started my current job five years ago this week. Reaching the level of senior technical writer brings me to ask whether I’ve got the smarts to go along with the time I’ve clocked.

A Narrow View of Tech Comm

When I graduated from Utah State University two months before starting as an intern, I thought technical communication consisted mainly of writing manuals, help systems, and the occasional tutorial. I thought the main activities were writing and creating images for print or Web.

My definition of a technical writer didn’t differ much from most people’s if at all.

I hadn’t heard the terms CSS, single sourcing, structured authoring, DITA, social media, Agile, RSS, SEO, or content strategy. Some of these things were either relatively new or not dreamed of at that point.

I belonged to the student chapter of the Society for Technical Communication, but the chapter members mainly learned from each other. There was only so far we could go that way.

› Continue reading…

Bookmark It

Hide Sites

I was out of town over the weekend, and I managed to post once. But I came back pretty far behind in my Google Reader. An April 21st post from Communications from DMN reminded me of an article I read in STC‘s Intercom magazine issue on DITA over the weekend.

I wrote a post on the subject of single sourcing recently with some of the same sentiments as the DMN post, but Scott made some other points that I agree with. Basically, don’t jump on the single sourcing bandwagon without thorough analysis, and at the end of the day, your content management methods are transparent to the consumer of your information. Single sourcing exists for the benefit of the writer, not the user, at least not directly. (You could argue that if the writer is working more efficiently, the user benefits.)

However, Sarah O’Keefe’s Intercom article, The Hidden Cost of DITA, did make me think about one pro of single sourcing: You have fewer places to update when you have to make changes. Currently, with a couple of ongoing development projects I’m on, when there’s a change to existing functionality, I have to think about the corresponding effects in the documentation. Due to the fact that the projects are ongoing, I’ve written the documentation recently enough that I can usually locate those places quickly. But what about later on, when my memory isn’t so fresh? Or when someone else has to take over maintenance of the material?

And so the discussion continues. But where I work, we tend to watch what’s happening in the industry and let the best practices come out on top rather than taking hold of something because it’s the rage. I think that’s a comfortable place to be. In the end, it’s probably the least expensive because we can carefully weigh pros and cons of switching our methods. If a craze passes before your analysis is done, you’ll probably be glad you took the time to do it. If the hype continues, there may be some substance behind it.

Bottom line is that switching to single sourcing schemas like DITA is not a decision to be made lightly. Remember, your users probably won’t know the difference if your strategy doesn’t affect your content.

Bookmark It

Hide Sites