Latest posts by techwriter (see all)
- How Much Money Can Writers Make? - June 22, 2017
- 2 Methods to Avoid Gender Ambiguity - June 21, 2017
- How to Write in “Action Units” in Technical Writing - May 31, 2017
© Ugur Akinci
Don Bridges, Commercial Tech Docs Manager at dclab.com has good points about converting legacy documents to XML in general, or to a DITA platform in particular. During a webinar he presented last week, a presentation sponsored both by Data Conversion Laboratory (www.dclab.com) and Single-Sourcing Solutions (www.single-sourcing.com), he raised a number of questions that need to be asked before investing your resources to such a conversion project.
First off, WHICH documents should you convert? Would they be the oldest documents? Perhaps not. The chances are it makes sense with a small pilot project and convert more recent and most popular documents. Why invest time and energy converting a little-used document that needs a major update?
Which platform should you choose? At this writing DITA seems to be a popular XML platform. But should you hire a consultant who is already up-to-speed with the intricacies of XML conversion or should you train yourself and/or your staff for an in-house capability? Should you learn (but lose time) by committing your own errors or gain time by paying someone who has already committed those errors and (hopefully) learned from them?
As far as I’m concerned, the toughest part of such a project is to gain management buy-in. How are you going to justify such an effort to the management? The question is both obvious and obscure: in dollars and cents of course. But how are you going to calculate that? How do you find out the ROI (Return On Investment) on such an initiative? Perhaps you should send an email to Don (firstname.lastname@example.org) and ask for DCL’s “ROI Calculator” to help you along the way.
The second hard task is to identify those text chunks (complete sentences, preferably) that might be saved in your CMS (Content Management System) database as a “topic.” That requires a committee work; getting together with your fellow technical writers and deciding how to standardize descriptions and eliminate variance.
For example, consider the following sentences:
1) “Click Open to launch the file browser window.”
2) “Click Open to open the file browser window.”
3) “Click Open to launch the file browser dialog box.”
Is there a good reason to express the same idea in three different closely related but not identical manner? Probably not. Those three sentences seem to be an ideal candidate for the following DITA “topic”:
“Click Open to launch the file browser dialog box.”
Next time you need to say that, you do not need to type it anew. You just call it in from your CMS database and it’ll be inserted automatically where it belongs.
For short documents that is no problem. But imagine thousands or tens of thousands of pages of legacy documents generated over a decade or more…
How are you going to go through all those pages, identify the expressions that need to be standardized, and then come up with a new “conversion table” of standardized “topics”? It can be a daunting task – and expensive as well.
During his webinar, Don gave the figure of $60 per page as average cost of legacy document conversion. It does not sound like a far-fetched a number to me. So if you are facing to single-source 1,000 pages , your organization should be able to budget $60,000 for the project, give or take a few thousands. Who said productivity comes in cheap?
Yet, despite the cost, in the long run you may not have any other good option anyways. If carrying your legacy content to mobile platforms (iPad, iPhone, Android phones and tablets) will make or break your organization’s future, for example, then you’d better start budgeting your structured authoring team sooner rather than later since the more you wait higher will be the cost you pay at the end in terms of missed market opportunities.
It’s an old saying that I like: “FAST, CHEAP, GOOD… choose two.” It applies in this case as well.