Every documentation tool has a built in information design bias. When you choose a tool, be it FrameMaker, DITA, AuthorIt, a WIKI, or SPFE, you are implicitly choosing an approach to information design. If you don’t understand and accept the design implications of your tool choice, as many people do not, you are setting yourself up for expense, frustration, and disappointment.
I was astonished at Sarah Maddox’s statement, in her guest post Why don’t technical writers use wikis — or do they? on I’d Rather be Writing, that wikis are not good at topic-based writing. Huh? Wikis are all about topic-based writing. In fact, it is the only type of writing they really support.
What’s wrong here? It certainly isn’t that Sarah does not understand wikis. If you want to know about using wikis in technical documentation, Sarah is the first person you want to talk to. If anyone knows wikis, it’s Sarah. She’s even written a book on the subject. What’s wrong, apparently, is that the term “topic-based writing” seems to have been corrupted or co-opted and robbed of its proper meaning. This is serious, and it needs to be fixed.
I was flattered that my post Technical Communication is not a Commodity was used as a catalyst for Scott Abel’s discussion with Val Swisher, Jack Molisani and Sarah O’Keefe on The Changing Face of Technical Communications, What’s Next? I had a fair amount to say in the comment stream that followed to defend my assertion that Tech Comm is indeed not a commodity, but since then a few other interactions have convinced me that there is another important trend in tech comm that should be recognized: the growing segmentation of the field.
What constitutes a “real” XML editor? The question is perennial, but is made topical by Tom Aldous’ surprisingly shrill defense of FrameMaker as an XML editor. It is unusual for a market-leading company to indulge in myth-busting aimed at tiny competitors. It is an approach more common to the small and desperate. But if we look past the oddness of Adobe employing this tactic, we see that the question of whether FrameMaker is a real XML editor, as with almost all debates about what makes a “real” anything, is not a debate about the product’s features, but a debate about what “real” means in the context.
It is well established that we are happiest and most productive when we are working in a state of flow. Accordingly, any interruption of the state of flow can have disastrous results for productivity. The interesting question to me is, what constitutes a interruption, and what is part of the flow.
Is fixing a bad page break an interruption of the writer’s flow, or part of it? What about looking something up in the style guide? What about searching the CMS for a topic to create a link to? If, like me, you answer that these things are all interruptions to flow, not part of the flow, perhaps you will agree with me also that by and large tech writing groups are not set up to make writers as productive as possible.