The transition from DTP to structured writing continues to be a bumpy one, and content management issues continue to plague many implementations. In many cases, the content management strategy depends on writers structuring things properly and they fall apart when writers fail to do so. For instance, reuse of chunks of information ought to make translation easier and less expensive, by reducing the amount of text to be translated. But often, chunking presents a problem for translators, as described here, because the chunks turn out not to be as context-independent as they were supposed to be.
Why does this kind of thing happen? In many cases, I suspect, the root cause is a failure to consider the importance of feedback in the design of the system. It is rather a puzzle why desktop publishing should ever have been as successful as it was, and in many ways still is, in technical communications and corporate publishing. DTP is based on a cottage industry model of production — each individual working alone in a cubicle producing one book at a time, with no co-ordination, no sharing of resources or content — that pretty much every other industry had abandoned by the end of the eighteenth century. It was just not the way industry did things. Certainly not the way they did things in any other part of their organizations.
But desktop publishing does one thing really well: feedback. WYSIWYG interfaces provide instant feedback to the writer that what they have written will publish exactly as they see it on their screens. The importance of instant feedback should not be underestimated. It is not simply that it allows the writer to work with confidence (though that is a big plus in itself). Numerous studies have shown that the cost of fixing an error raises steeply the longer it goes undetected. Instant feedback means that errors are caught instantly, and this means they are very cheap to fix. This can go a long way to compensating for the inherent inefficiency of the cottage industry model of production.
A long way, but not far enough. The feedback that DTP gives is based on appearance in one media. It does not produce data that is easily or reliably processable, reusable, integratable, configurable, or exploitable for other purposes. And so we come to structures writing and content management. The problem is that too often, in implementing these systems, people forget the basic lesson of DTP: that feedback, delivered as quickly as possible, is essential.
To be clear, the feedback needed here is not the same feedback that DTP provides. One of the great difficulties in moving writers to structured writing is weaning them off WYSIWYG feedback. Vendors don’t help, in this regard. They rightly observe that writers who have relied on WYSIWYG feedback for so long feel lost without it, and so the provide a WYSIWYG (or as least, something resembling WYSIWYG) interface over the structured content underneath.
The problem is, feedback is what tells you when you have done the job correctly. WYSIWYG feedback tells you, if it looks right, it is right. But if you are trying to produce structured content, looking right is no guarantee of being right. You can hopelessly butcher the structure and still have the content look right in one organization for one media. But when you try to process, reuse, integrate, configure, or exploit that content, the usual result is the digital equivalent of blue smoke.
So the first thing you need to do it to train writers to accept feedback on the structure of the content rather than its appearance. We have very good tools for doing this, but we don’t always use them, and we don’t always use them well. Your XML schema should be providing immediate feedback to the writer on the structure of the content. However, most of them are far too loosy-goosy to do this properly. (This is in no small part because writers will fight you on strict schemas because they are still trying to produce ad hoc layout effects. Structured writing does not have the visual flexibility of DTP, and it takes a while to persuade writers that the trade-offs are worth while.)
Just as important as schema design, however, is process design. The purpose of structured writing is to make content processable, and if your feedback to the writer is going to be meaningful, you need a reliable processing system that correctly handles the content in all the ways you need it processed, based on its structure. Based on its structure is the important part here. Too many of the systems in place today rely far to much for processing on the input of writers to define the processing parameters in each case. A perfect example of this is DITA, which supports reuse not based on the inherent properties of the content, but on maps, drawn individually for each reuse scenario, by writers.
Why is this a problem? Well, first of all, there is the overhead of creating all those maps, and (as is increasingly becoming apparent) the overhead of managing them and versioning them. But besides this, it means that the success of the chunking of the content for reuse, or translation, can only be judged fully after the map is drawn and processed. The topics don’t contain the structure and metadata that drive the reuse, so there is no mechanism to provide timely feedback to the writer on the eventual processability, reusability, and translatability of the content. Where translation issues are involved, the feedback loop may never reach the writer at all.
And the problem with long feedback loops is that even when the feedback does reach you, the feedback loop to verify the fix is just as long as the original feedback loop. Because the feedback loops are long, errors are hard to catch and hard to fix, with the result that they accumulate in the system. Things may be appearing to work very well for a while, but eventually the accumulating errors start to slow things down, and can eventually make them grind to a halt — as very many content management implementation do.
It may seem like a small thing, but to neglect it is deadly. If you hear the words “it will work fine as long as the writers remember to…”, know that trouble is coming. Writers are people — busy people with a lot of information to juggle — and if they don’t get fast accurate feedback, they won’t always “remember too…”. Want to know if your structured writing or content management system is going to work as well in five years as it does today? Sit down and calculate the length of the critical feedback loops — from when a writer writes something to when they know that they have, for all necessary purposes, done it right.
Iconic One Theme | Powered by Wordpress