(This is the eighth post in a series on the publishing industry’s new product categories.)
The problem many publishers are facing is that their titles need to be reused in a variety of contexts.
Book apps are very unfashionable at the moment but there is a brisk trade in small, fairly cheap, and functional apps based on book content, where the content is often licensed by a small app development outfit from a small publishing outfit or book packager. These range from military history apps, to children’s apps, to travel guides and in many ways are prototypical Content Development Kits like I described in an earlier post.
Then we have a variety of web and app gateways popping up that sell access to ebooks on a subscription basis, either directly to consumers or to libraries or other educational establishments.
The source format for these apps is often an EPUB version of the title and this is, in the cases I know, the source of a lot of problems and complications. The structure of the EPUB doesn’t tell the app developer where to hook the functionality of their app into the title’s content. This means that the app developers have to spend considerable time adapting and editing the text of the title and its structure. In some cases they have to spend more time on pulling structured text out of a crap EPUB than on the development of the app itself.
For most large publishers they see development as the single biggest cost of creating apps from their titles. This is because they are focusing on the digital equivalent of a tent-pole blockbuster movie. Small publishers and small app developers tend to focus on smaller scale apps with a much bigger emphasis on code reuse. For them, anything that cannot be automated is a liability and a cost centre.
You can think of a structured ebook file as an API. Most existing ebooks don’t need any API capabilities. A novel benefits little from it.
Reference books, however, gain immense value from becoming detailed and functional APIs in the digital space.
A reference book that is the source of only one or two concurrent editions in print can be the content source for hundreds, if not thousands of apps. A classic example being the dictionary services built into Mac OS X and iOS.
Any reference title can be a similar source provided that its content has been made available as an API.
Unfortunately, we don’t have many formats or tools that make this easy, making a lot of these services custom jobs.
Rewind
Stop. Go back. Reread. Can you tell what the big problem is with what I wrote above? The idea that publishers could benefit from turning their titles into well structured ebooks—files that can serve as APIs—has a fatal flaw:
Only certain kinds of books have the internal structure that suits this purpose. Books that can be mapped onto a database structure (e.g. reference books) work perfectly. Structured non-fiction tends to work well. Anything that has a story less so.
Even the most structured dictionary or reference book is still not flexible enough to really suit the purposes of app, web, and interactive media developers. They need more. They need content that is adaptive.
What they need are structured projects that offer enough variety in their fabric to adapt to varying devices and context. Instead of single length chapters you need entries that have full-length, abridged, even more abridged, and tweetable versions of the chapter’s content. You need the chapter’s full title, tweetable title, display title (if different). Every chapter needs descriptions of varying lengths (like the chapter’s content). Do that for every chapter in the project, mark it up so that it’s usable, and you’ve got the beginnings of something really flexible.
Adaptive content
What this means is quit thinking that what you are doing is designing and creating for the final presentation. You’re not in the business of making brochures. You’re not in the business of mobile applications. You’re not in the business of making web pages. You are in the business of making content and structuring that content so that it’s presentation independent, so you can get it out onto whatever device or platform you want to. (Karen McGrane – Uncle Sam Wants You to Optimise Your Content For Mobile)
Adaptive content—making things work for mobile, web, desktop, apps, tablets—is not just a design problem but an authorship, business, and editorial problem.
A large content library is not an asset in this context but a liability. It’s an ossified monolithic resource when you are surrounded by small and nimble players using small and flexible resources. The individual smaller players do not represent a threat—most of them are more likely to fail than not—but as a whole they do. Where each one may only address a tiny sliver of your back catalogue’s target market, they do so with content that is more flexible than yours because they had to start from scratch. Or, they have had the time and focus to adapt it by hand because their survival depends on this one title, which is a level of attention you can’t give to tens of thousands of titles.
As a collected whole, the smaller web players, self-publishers, three person publishing houses, indie app developers, and the like, are much more likely to be able to properly leverage the advantages of digital publishing than a large publishing mega-conglomerate. Publishers approach each edition as something that demands a unique design, custom editing, and detailed work to adapt the title’s content to that editions particular form. This isn’t scalable, neither in terms of labour or cost.
Adaptive content is essential when we face a plurality of devices. Having a ‘mobile content’ strategy means that you are just making the same dumb mistakes again because there will be other platforms in the future, and if your content isn’t readily adaptable you’re just going to face the exact same problems again that you are facing now with the mobile transition.
Not to mention the fact that you are opting out of a revenue stream from licensing your catalogue to various developers.
Your existing non-fiction titles are flies caught in amber. They exist only as evidence of a single evolutionary context, incapable of adapting or changing to survive in a new one. Because of the costs and work involved in making an extensive back catalogue adaptive, it becomes a liability when competing with a host of smaller outfits starting from scratch.