Breaking the batch habit
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.
About the author
Daniel Beck
If nothing else does the trick, I imagine this problem will fix itself, by sheer force of demographics. As a young technical writer (having held my first internship in the field five years ago), I’ve never once been in a batch publishing situation, and, if I have anything to do with it, never will. Current batch publishers resisting the change will one day be outnumbered by those of us who have never worked under that onerous regime.
Sarah O'Keefe
Hi Daniel,
This is an interesting point, especially when you look at Larry’s comment below yours. Not all younger tech writers have the luxury of picking and choosing their environment.
That said, the business reasons for moving away from batch publishing are compelling, so the industry will get there. Eventually.
Larry Kunz
Never mind any of that. Where can I get some of those cupcakes?
As long as there’s demand for printed collateral, like traditional manuals, I don’t think we’ll be able to close the gap. We’re going to be stuck with publishing large amounts of content infrequently. There’s just no other way, given the realities of printing, storage, and distribution.
We’ll close the gap a little when we can replace the big manuals with smaller printed pieces like installation brochures. We’ll close it much more when everything — printing, storage, and distribution — becomes electronic. We have the tools to do that today, but many of the companies who pay us don’t want to hear about it.
Perhaps it falls to us technical communicators to educate our clients and employers about the business value of just-in-time publishing — just as we’ve had to educate them about our own value.
Sarah O'Keefe
Hi Larry,
Here’s an amazing local vendor: http://www.acupcakebar.com/ (I chose the pictures for visual appeal and Creative Commons license—no idea where those vendors are!)
Our clients are started to demand just-in-time publishing. Or, more accurately, their business need is to shorten the delay between product shipment and documentation delivery.
The major problem I see is that most techcomm tools don’t support incremental publishing. We’re building a lot of custom “stuff.”
Mark Baker
Hi Sarah,
I agree this change is both difficult and necessary. The change does not start at the tools level. It starts with information design. Even though more and more people are learning to write in topics, they are still creating topics that have hard dependencies on other topics, and still mapping and managing those dependencies largely by hand.
Even if we addressed the comparatively trivial tools issue of being able to publish the last blessed version of a topic while work is in progress on the next version, we would still be stuck in wedding-day publishing as long as it remained necessary to manage the dependencies of each topic to ensure the successful publishing of the whole.
The fundamental problem I see here is that writers are accustomed to expressing the relationships between subjects as the relationships between topics. Thus the understanding of the structure of a system or its workflow is expressed by an organization of topics (or the organization of a book).
The solution I advocate will come as no surprise: Every Page is Page One topics. Every Page is Page One topics express subject-to-subject relationships (usually through links) but they do not have topic-to-topic dependencies. There is no previous, next, or parent topic. Each Every Page is Page One topic and be published when it is ready, without the fear of breaking topic-to-topic relationships.
The web, of course, is full of Every Page is Page One topics. User of WordPress and Drupal will frequently be writing blog posts or web pages, which tend to be Every Page is Page One by nature.
But while it is easy enough to create one-off Every Page is Page One topics, writers faced with producing a large body of related information on a product or process have a hard time figuring out how to express this information in a way that preserves and expresses the relatedness of the subject matter without expressing the relatedness of the subject through the relationships of the topics.
Until we learn to do this, we will have a hard time moving away from wedding-day style publishing. To Daniel’s point, the generation raised on blogs, tweets, and Facebook may very naturally figure out how to express these relationships in ways that are compatible with an Every Page is Page One information design. EPPO is, after all, the default information design of the Web. But can we afford to wait for generational change to address the problem? I don’t think so.
Joseph Lorenzini
Very interesing. I live the wedding day every three months because my company follows an agile SDLC and since I am the only writer, and I deliver almost entirely pdfs, my life is very painful during that time.
I have two comments on this.
1. One I do not subscribe to the one information architecture to rule them all. A deliverable should be based on a business case. The business case is inevitably going to depend on your audience and what your audience needs. And I do not buy that topic based authoring is going to be a suitable answer for everyone in every situation. I see topic based authoring as a popular, common, and useful depending on the business case and the audience.
However, there are many, many complex topics that require topic-to-topic dependencies and use hieracrchy to provide the user a guided learning experience. I believe we call this a book. 🙂
My prediction is that instead of topic based authoring replacing books, we will need to do topic based authoring in addition to book based authoring. The topic based authoring will be the first contact that end users have with documentation, and will be used to guide writers in determining what topics actually need book level treatment.
In other words tech writers get the worst of both worlds as it were. We will have wedding day publishing and day to day publishing too.
2. Frequently, you must work in the environment that you cannot control. This means dealing with a distribution platform that makes topic based authoring virtually impossible. In my case, I must distribute all documentation through salesforce.com and my company will NOT use any other mechanism to do this for a variety of business reasons. SF.com is an evil, horrible, unbelievable awful distribution mechanism for any type of documentation. The search mechanism is atrocious and they don’t supported hierachical folder structure.
In that kind of environment, PDFs is the best you can do. I suspect that this issue will be addressed once legacy technology dies off in the next 15 to 20 years but until then I bet PDFs will be the primary deliverable for a lot of enterprise environments. I am not saying that’s a good thing; but moreso just making an observation.
Mark Baker
Joseph, I am with you entirely. Sometimes we need topics; sometimes we need real books. What we don’t need, and what we are too often stuck with, is books made out of topics — what I call Frankenbooks (http://everypageispageone.com/2012/02/24/frankenbooks-must-die-a-rant/).
When we need real books, we should write real books. I think we often think we need real books, because real books are what we are used to. Real topics might actually work better, once we go our heads around writing that way. The bottom line is that unless a reader is willing to read a real book, you don’t need a real book. But if you do have a reader who wants a real book, they want a real book, not a Frankenbook.
Frank Buffum
*Ideally* we could write real books when we need them, topics when we need them. But since many of us are already in what Joseph called “the worst of both worlds,” we have to find a way to create topics that can read reasonably (if not perfectly) when assembled as books, yet will work independently to enable reuse and more agile (not Agile) publishing needs.
The threat of the Frankenbook is very real. But whether we are consultants or employees, we cannot expect our clients to comply with our standards of how to do it The Right Way.
Catherine Woods
Sorry, but I just have to mention that your cupcakes look great!
They make the article much more friendly.