(This is the tenth post in a series on the publishing industry’s new product categories.)
The reason why the term ‘book app’ is so dangerous is that it blinds people to the sheer variety there is in content apps and to the many possibilities apps and websites offer.
(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.
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.
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.
Yesterday, I wrote a post on ebook silos and missed opportunities.
Some people seem to be missing the core criticism in the post. The problem, as I see it, is in the infrastructure and in the market we have in place. This is not a lament for how lazy people must be or how stupid existing developers are for not implementing these things already.
Existing ebook reading apps are bland out of necessity. The ones implemented by silo owners need to appeal to and be useful to everybody. They can’t not be generic. Specialisation is not an option when you need to appeal to the lowest common denominator.
The independents have a different problem. They need to both implement detailed support overly complex file formats and they need to target one of the silos (generally Adobe’s playground, which is a fraction of the overall market).
Because the market involved is so small and the end result is that their apps have to have broad appeal. A specialised app targeting a fraction of a fraction of a market is not economically viable when you are employing a team of developers.
The solution to this conundrum is both simple and difficult (like so many simple things are).
Generally speaking, the way to promote variety in any given software genre is to make sure that it’s possible for a solo developer or a small team of developers to create and maintain an app in the genre. Only a solo developer (maybe a duo) can hope to make a living by addressing a fraction of a fraction of a market.
I’m convinced that, if a solo developer found a way to implement one a specialised ereader that was useful and valuable to readers, they’d be able to make a decent living from said app.
One such example is Marvin. It’s an ereading app that focuses on configurability, text analysis, Dropbox support, proper annotations export, and a lot lot more. It is quite different from most other ebook reading apps in the market and is quite excellent. It’s not for everybody, but it is unique enough for there to be a large group of people who both have been waiting for an app like this and are eager enough to use it that they are willing to break the DRM on their existing library to use it.
Anybody who is in any way dissatisfied with their current ebook reading app owes it to themselves to try it out.
Which brings me to the compromises needed to make the byzantine mess that are ebook file formats manageable by a small team. Marvin offers a few pointers in that direction:
Now, Marvin owes a bit of its success to luck, but I still think it offers us hope for how things could go in the future. Solo developers and small teams will experiment with apps. Some will fail. Some will succeed.
Possibly, but that’s not what it’s for. As I see it, the primary goal of the Readium SDK is to get large corporations who are competitors to collaborate on improving their support for the various incredibly complex flavours of EPUB (2, 3, FXL). This is hard enough without trying to address the needs of solo developers as well.
The cost of acquiring a license usable in a commercial product bears this out. After September you need to pay $60 000 to join and get a license or you need to contribute work and source code. Both are going to be way beyond the means of a solo developer attempting the already difficult and risky task of a specialised ebook reading app.
And that’s okay. Readium SDK has an already unenviable goal (achieve full format support in all major big-corp generic readers). Maybe once that’s achieved and all major apps have shipped with full EPUB3 support, maybe then the foundation will reassess the licensing terms. Before then they are more than justified in focusing on trying to solve the problem they set out to solve.
More publishers going DRM-free would help a lot, especially those catering to less price-sensitive specialist subjects. That would open up the market for a developer to enter with a specialised app catering to those readers.
In fact, O’Reilly’s pioneering work with DRM-free might well be an opportunity for a developer-oriented ebook reading app, one with built in REPLs and consoles for various languages. Imagine being able to run and play with example code in a variety of common languages from a dev ebook just with a tap. Imagine having access to each platform’s documentation as you read a book on a specific problem area; having access to the official documentation for a method with just a tap.
More comics publishers following the example of Image Comics (they sell DRM-free comics direct, not enough of them yet, but it’s a start) or Thrillbent might open up the field for a specialised comics-oriented ebook reader, one that only supports FXL ebooks and PDFs. They might even be justified in only supporting PDFs and CBRs.
I’m convinced you don’t need full EPUB3 or DRM support to create an excellent app that is sufficiently useful to enough people to be a viable business for a tiny team.
The app would have to be specialised and solve very specific problems for very specific group of people with very specific needs. Just making an ebook reader with cool and unusual features isn’t going to work again, even if it did work for Marvin. You need to both delight and remove pain. Delight alone will not do.
I’m not saying it would be easy. It’s clearly a difficult problem. But it would be interesting.
Studio Tendra 