The batch publishing paradigm is deeply ingrained in technical communication, and breaking out of it is going to make the transition from desktop publishing to structured authoring look easy.
I wish this were my idea, but I think it was Mark Baker from whom I first heard about this issue. There’s a discussion in the comments of his It’s Time for a New Doctrine of Technical Communication article about “wedding day publishing” which he describes as:
“months of planning […] executed in a […] desperate panic lest any missed detail should spoil the immortal memory of the great day”
Instead, Mark says we need
a system that is always in a publishable state, and in which publication is not a great event, but a normal part of everyday life
Nearly all of our technical communication tools are intended for “deliverables.” That is, you work on a book, help system, web site, or other unified presentation of a lot of content and at some point, you push the Big Red PUBLISH button. Of course, this system makes a good bit of sense in a print world, where creating a book involves messy manufacturing processes—paper, ink, glue, not to mention a printing press.
It’s like cupcakes. Producing two dozen cupcakes is pretty much the same amount of work as producing a single cupcake, so it makes sense to create them all at once.
Imagine producing a book in small increments. You would:
- Write page one.
- Send page one for edits.
- Get page one edited, reviewed, and so on.
- Send page one to the printer.
- Write page two.
- Send page two for edits.
- and so on…
This is pretty clearly not going to work for anything more than two pages of content. But in a digital environment, we can do exactly this—write a small amount of content and make it available to our readers as soon as it is ready. Not only that, it’s quite easy to go back and fix stuff. If, for example, there is a typo in this post (notice that I did not use the subjunctive there [UPDATE: found one!]), I can fix the typo after the initial publication and only those of you who follow our blog obsessively will ever know about it. (And there aren’t THAT many of you.)
Our technical communication paradigm must move away from the 500-year batch publishing habit and toward a nimble just-in-time publishing model.
Most web publishing works this way. Applications like WordPress, Drupal, and others assume that you publish small bits of content frequently. But most technical communication tools assume that you publish large amounts of content infrequently.
We must develop processes that close the gap between tech comm and our readers by eliminating time-consuming processes and publishing content in small increments.