Manuscript First: A more efficient, pragmatic path to cross-platform publishing
For many publishing organizations, one important topic is the way in which the same content is delivered to different media and different devices. This is sometimes referred to as cross-platform publishing.The modes of delivery that the market requires are broad, and may include print, Web/HTML, e-ink reader (e.g., original Kindle), LCD reader (Kindle Touch, Nook Tablet), tablet (iPad) and smartphone (Motorola Droid). The array of delivery formats will surely only grow.
In the early days of e-delivery, some publishers pursued a quick approach to multi-device delivery by distributing their content as PDF files or some derivative. In other words, all of the delivery platforms displayed content as it appeared on the printed page. The immediate issue with this approach is that this format only looked good on, well, the printed page. Publishers can no longer get by with the PDF approach—beyond using PDF for sampling of the print product—for the simple reason that the marketplace is more sophisticated now, and customers will no longer accept PDFs as viable e-delivery.
For a product to be successful, delivery devices must display the content in a manner optimized for that device. In other words, visual style must be device-specific, and “device-agnostic” content must be merged with these device-specific styles.
Two traditional methods of addressing this challenge exist. The first is to contract with a conversion services organization that will take content in one format and—via manual or semi-manual processes—convert it to another. The typical scenario involves the publisher providing the file(s) used for creating the printed work (PDF and/or Adobe InDesign), for the service provider to convert to an e‑book format, e.g., an EPUB file. This often is referred to as the “Print First” strategy, because the version of the content as designed for the printed page is produced first and iterations are based off of it.
The “Print First” strategy is easy to implement, but less than ideal. The service can cost from $150-$600 per title, not including the costs of the publishers’ staff to perform quality assurance on the conversions. Second, the semi-manual process is not instantaneous, and there may be latencies to completing conversions. Third, the service provider—and not the publisher—becomes the expert of the process, which fosters dependence on the provider.
An alternative approach is for the publisher to build and maintain a technology platform that can produce versions of content for each platform. This is often based on the philosophy of “XML First” in which content is created in a format that is device-agnostic—not visually styled for any specific device. This “XML First” approach generally involves the acquisition and integration of complex and often expensive software, such as digital asset repositories, XML databases and workflow management systems.
The challenge with such a capital-intensive approach is that even if an organization had access to such capital resources (often in the millions of dollars) the technology may become obsolete before it is fully amortized. Worse, the “XML First” approach typically involves a wholesale reworking of core publishing business processes, which tends to be met with suspicion by a sometimes-dubious staff.
Over the past year, a number of cross-platform publishing success stories have emerged that indicate a third practical approach. It is, in some ways, a cross between “XML First” and “Print First.” This third approach, which might be named “Manuscript First,” involves the creation of a manuscript that conforms to specific conventions or standards as defined by the publisher. This is most often implemented in Microsoft Word by the use of standard Word style names to create a “well-formed” manuscript. (A “well-formed” document is one that adheres to pre-defined conventions.)
The standard styles typically represent the structure of the book: “Chapter Name,” “End Note,” “Citation,” etc. These structural labels are applied to the text as Word styles, much in the way that structure is defined in XML files in the “XML First” approach. Indeed, Word’s DOCX file format is based on XML.
When a well-formed manuscript created in Word’s DOCX format adheres to a standard set of style names, it can be automatically processed by software. Therefore, the translation of the book into a variety of delivery formats—such as e-reader, Web and even print—can be automatically generated. This automation is enabled through the use of output templates that also use standard structural labels. By having both the source manuscript and the output templates using the same structural tags, one can be programmatically mapped to another.
The automated output of the various delivery formats based on the standard manuscript can be performed by systems and service providers for a fraction of the effort of the standard conversion services. One compelling option is performing the automated conversion with the use of a third-party cloud platform. That way, a publisher can achieve automation without building its own system. An attractively economical path.
Automated output has its limits. Highly illustrated works or those with complex layouts may not lend themselves to this approach. However, for many publishers whose works do not have complex designs, “Manuscript First” may be essential for profitable digital publishing programs.
I recently met with a small press that publishes between 60 and 90 titles per year. Currently, it is releasing fewer than 10 e‑book titles a year, due to conversion costs. When it adopts the “Manuscript First” approach, it will be able to economically release all titles on all formats, all at the same time. Isn’t that the goal we all have?