Did you ever have to make up your mind?
Pick up on one and leave the other behind? — The Lovin’ Spoonful
The current situation in the technical communication world reminds me of this great old song from The Lovin’ Spoonful. We’ve got two attractive technologies competing for our attention: social media and structured, intelligent content (PDF).
We were getting all set to start a long-term relationship with structured content, when along came social media and we lost our heads.
We’re attracted to both for good reasons; each addresses a set of significant problems. Structured content and XML are so far unequaled for manipulating, reusing, combining, and publishing content. And social media, especially wikis, satisfies the need for humans to interact effectively and efficiently.
The dilemma is that even though they address distinctly different sets of problems, with little overlap, it is surprisingly difficult to take advantage of both methodologies with a unified set of tools.
The Case for Structured Content
Structured content arguably improves overall productivity, but it does so by focusing almost exclusively on production, not writing. You should be able to write less content overall if you’re really good about reuse (PDF) and re-purposing, and that is a production gain. And, you can gain productivity in your back-end processing through single-sourcing.
However, you are not likely to increase “the amount of useful and unique content created in a given amount of time.” That is, your writing productivity is not likely to increase and may even decrease. This is likely to be the case even if you’re moving from a WYSIWYG environment, and writers no longer need to worry about formatting.
The Case for Social Media
On the other hand, social media, especially wikis, directly address writer productivity. Consider how much easier it is to author content with multiple writers, review and edit content, and bring in collaborators, when you’re using a wiki. And, most wikis are much easier to use than even the best structured XML editors.
However, with the current technology, wikis are not particularly good at structure; in fact, in my experience they are miserable at structure. If you’re lucky, you can export HTML, and if you’re really lucky, you can export XML (I’m working with one right now that looks promising), but I have yet to find a wiki that will handle XML in a native form (NB: There are lots of wikis around, and I would really like to be proven wrong on this point, so please post a reply if you know of a such a beast). That means that with current tools there will be an “export break” between your editing environment and your production environment.
What’s a Writer to do?
At the moment, we are forced to make up our mind and say yes to one and leave the other behind. But, it shouldn’t be that way. Unlike the dating world, there is no inherent reason to force a choice. The two approaches are complementary and could be combined with the right tools. It just hasn’t happened, yet.
There are workarounds. XML Press has been successful at developing publications using an HTML-based wiki with a DocBook XML back-end, but we still have an export break as we move a publication from wiki-based authoring to XML-based processing. And there are encouraging signs with the development of browser-based XML editors like Xopus and DITA Storm, but we still could use a true integration of an XML content management system and a capable XML-aware wiki front end.
About the Author
Richard L. Hamilton is Founder and Publisher of XML Press, which is dedicated to producing high quality, practical publications for technical communicators, managers, and marketers. Richard is the author of Managing Writers: A Real-World Guide to Managing Technical Documentation, and editor of the 2nd edition of Norm Walsh’s DocBook: The Definitive Guide, published in collaboration with O’Reilly Media in 2010.