For his 1959 horror movie The Tingler, director/producer William Castle had movie theater seats rigged with buzzers to scare moviegoers during a scene when the Tingler creature is loose in a theater. Patrons in those seats probably didn’t enjoy the jolt—or making a spectacle of themselves because of the Tingler’s “attack.”
If you can’t handle some rough-and-tumble adversity, you are not ready to manage the implementation of a new content strategy.
Yes, you can call me overly cautious.
Before making a purchase, I will research the you-know-what out of the item. If it’s a big purchase, I’ll hire a professional to help me make my decision (particularly when it comes to real estate). I’d rather part with a bit more cash than get angry with myself later for a bad purchase.
I’m about to replace an old toilet, not-so-affectionately nicknamed the Lazy River.
When selecting authoring and publishing tools, there is an unfortunate human instinct to cling to the familiar. This ranges from a slight preference for the tool currently in use to “You will pry this software from my cold, dead hands.”
When I started at Scriptorium a year ago, I knew almost nothing about tech comm. I knew what technical content was, having used it many times, but I’d never really thought about how it was produced.
The elimination of the distribution monopoly for content is upending the publishing industry and technical communication specifically.
As technical communicators, our ultimate goal is to create accessible content that helps users solve problems. Focusing on developing quality content is the priority, but you can take that viewpoint to an extreme by saying that content-creation tools are just a convenience for technical writers:
The tools we use in our wacky profession are a convenience for us, as are the techniques we use. Users don’t care if we use FrameMaker, AuthorIt, Flare, Word, AsciiDoc, OpenOffice.org Writer, DITA or DocBook to create the content. They don’t give a hoot if the content is single sourced or topic based.
Sure, end users probably don’t know or care about the tools used to develop content. However, users do have eagle eyes for spotting inconsistencies in content, and they will call you out for conflicting information in a heartbeat (or worse, just abandon the official user docs altogether for being “unreliable”). If your department has implemented reuse and single-sourcing techniques that eliminate those inconsistencies, your end users are going to have a lot more faith in the validity of the content you provide.
Also, a structured authoring process that removes the burden of formatting content from the authoring process gives tech writers more time to focus on providing quality content to the end user. Yep, the end user doesn’t give a fig that the PDF or HTML file they are reading was generated from DITA-based content, but because the tech writers creating that content focused on just writing instead of writing, formatting, and converting the content, the information is probably better written and more useful.
Dogwood // flickr: hlkljgk
All this talk about tools makes me think about the implements I use for gardening. A few years ago, I planted a young dogwood tree in my back yard. I could have used a small gardening trowel to dig the hole, but instead, I chose a standard-size shovel. Even though the tree had no opinion on the tool I used (at least I don’t think it did!), it certainly benefited from my tool selection. Because I was able to dig the hole and plant the tree in a shorter amount of time, the tree was able to develop a new root system in its new home more quickly. Today, that tree is flourishing and is about four feet taller than it was when I planted it.
The same applies to technical content. If a tool or process improves the consistency of content, gives authors more time to focus on the content, and shortens the time it takes to distribute that content, then the choice and application of a tool are much more than mere “conveniences.”
