Adapt or die: Managing increasing content velocity

Sarah O'Keefe / Opinion1 Comment

Content velocity is the speed at which we create and produce content, the speed of the publishing process itself, and the speed of change in content requirements—what we need to produce and the delivery mechanisms.

This is a summary of a presentation delivered at the Intelligent Content Conference on February 8, 2013, in San Francisco.

Artist's rendition of a comet hitting Earth

Image: Don Davis/NASA

It’s not as though publishing has been trivial until now. Surviving and thriving as a content creator has always been difficult. But now, the environment is changing drastically.

We must adapt, even though we are not sure what we need to survive in the new environment. The asteroid—digital publishing—has hit us. We are seeing changes already, but are these temporary or permanent? What are the most profound changes? By comparison, the initial asteroid impact would have caused a huge shock wave, tsunamis, and other immediate disasters. But it was the dust thrown into the atmosphere that caused climate change and wiped out the dinosaurs.*

The impact of digital publishing is that content creators must stop operating as a cottage industry or in an artisanal bubble. We no longer have a margin for error in this new world.

Ostrich (Female)There are dinosaur descendants in today’s world, but they look completely different than their ancestors.

What are the implications for us after the arrival of digital publishing? How do we climb out of the crater and deal with the new landscape?

One key is velocity. Publishing speed is increasing in every content dimension. Most publishing systems are ill-equipped for flexible, fast, and changeable requirements. They are equipped to support a manufacturing process, not a digital process.

Authoring velocity

A requirement for faster authoring means that collaborative authoring will become the norm. A modular, collaborative approach, along with controlled language and terminology, speeds up authoring at the expense of individual voices. To make authoring faster, publishing and formatting responsibility will be taken away from authors.

Editing velocity

Software will take on some of the traditional human editor responsibilities; particularly, enforcement of required content structure and controlled language. The conformance edit will largely move into the authoring phase.

Production and distribution velocity

The process of production editing—putting the final polish on a specific output format—will disappear for almost all content. Instead, we will speed up the velocity of content production with automated formatting.

For online content, the friction of distribution is eliminated. This is not exactly new information. But most workflows, especially in technical communication, are still built on the assumption that print or maybe PDF is the most critical business driver. Creating a physical book takes time, so delays in content creation are acceptable. But now, creating the “artifact”—the actual thing that people can read—doesn’t take any time. Blog posts are distributed in a split second. That means we can’t hide behind the inefficiencies of the distribution process any more.

If you have done traditional book publishing, you probably remember these phrases:

  • Bluelines
  • Galleys
  • AAs — no, not AA, but author’s alterations
  • Film plates
  • Stripping
  • Page signatures
  • Old type

They used to be necessary to produce a book; now they are headed for historical status.

Localization velocity

Translation delays should be measured in days, not weeks. To achieve this, reuse of translated content is critical. Other factors that help increase translation velocity:

  • Reuse in source files
  • Machine translation
  • Translation memory
  • Terminology management and controlled language

Velocity of new ideas
Right now, we’re all talking Kindle and EPUB production, along with mobile strategies. But what’s next?

Intelligent content, meaning information integrated with the product. We have this in software as context-sensitive help; now think about the equivalent in hardware. Your refrigerator’s light bulb burns out, so you get a notice on the fridge screen, along with instructions on how to swap out the light bulb.

In version 2, the fridge orders its own light bulb from amazon.

In version 3, the light bulb is printed on your in-house 3D printer and delivered to the fridge by your house robot.

In version 4, who knows??

We don’t know what’s coming, but we do know that we must shred the veil that separates information, data, and products. That’s what intelligent content is all about. And when we free content from its physical bindings, we can start to see the real potential of the information age.

Digital is the technology.

Velocity is the requirement.

Intelligent content helps us solve the velocity problem by making the content itself richer and by making it possible to connect the content with the product.

* At least, that’s the best current scientific theory. None of us actually observed the event directly.

About the Author

Sarah O'Keefe

Twitter

Content strategy consultant and founder of Scriptorium Publishing. Bilingual English-German, voracious reader, water sports, knitting, and college basketball (go Blue Devils!). Aversions to raw tomatoes, eggplant, and checked baggage.

One Comment on “Adapt or die: Managing increasing content velocity”

  1. Hi Sarah,

    Our organisation is one where we see increasing velocity in the requirements for technical content. I think that the concept of a “structured wiki” (e.g. SDL’s LiveContent strategy) is one that could help manage this. The structured wiki is where SMEs can edit (or create) content directly in a web-browser, using the published material, but the content is still stored in a Content Management System in XML. Authors can access that content for edit, review, or restructuring, and can also publish it in other formats. To my mind, that is the way forward. Traditional wikis encourage collaboration, but the content is only stored on that wiki, available in a single format. That is not enough for technical publications; we need true source formats that can be published in other ways. If SMEs can access stub documentation early in the development cycle, and add to it directly throughout the cycle, that will help lessen the dependence on the authoring team.

    Malcolm

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.