(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.
Thinking in terms of ‘book apps’ narrows your options for adapting your books into digital down to either the form-limited ebook or the book app ghetto.
The problem with book apps as a concept is that it puts the form of the book before the outcome for the reader. A book app’s primary purpose is to adapt a piece of content into snazzy digital form. A successful app’s primary purpose is to effect an outcome for the user. You can’t accomplish the latter by focusing on the former.
As Amy Hoy says:
The outcome for the customer is more important than the tool, process, or skill used to create it.
The key with apps is to implement something that lets the user do something they couldn’t before.
Obvious examples off the top of my head:
-
Train and bus guide apps that include information from tour guide books.
-
Any database of items with a well-implemented search (essential: extensive awareness of alternative and phonetic spelling, bonus: new input methods such as sound or images).
-
Recipe databases that let you search by ingredients available and include how-to videos.
-
A film guide app that lets you look up an actor using either a picture (facial recognition) or clip of dialogue (voice recognition).
-
A birdwatcher’s guide that lets the watcher look up based on the sound of the bird’s call and presents a list of likely candidates when a photo is loaded instead.
-
Apps that do benefit from 3D: visual reference books for illustrators. They are also too small a market to be likely to sustain a 3D-heavy title.
Functionality trumps content. You can get away with mediocre entries in the app if you have excellent functionality.
The key is not to think of this as an adaptation of a specific title but a creation of an app that effects a specific outcome. The content is there to improve the outcome, not be the outcome.
Like I’ve said several times before, the better the title works as a book, the worse it’s likely to fare as an app. You want the titles that are limited by the book form.
That’s why the prevalence of database apps in the list is not a coincidence. Titles composed of structured individual entries are ideal for digital—provided you can tie the entries to the user’s desired outcome—and are often limited by print. The database structure also gives you an easy way to continuously update and improve the app—increasing its value—without requiring additional programming.
The added benefit of building databases is that access to them can be licensed. Instead of creating just one app whose outcome is improved by the database’s content, you can have several. Developers whose apps would be better and more likely to be successful with your database are going to want to license it—provided they can license it on reasonable terms. The problem, for the publisher, is that developers need to be aware of the opportunity. For that you need to do a lot of relationship-building with the developer communities (yes, plural).
Building a good app is both complex and requires a lot of expertise. Publishers planning on building an in-house app development team are only planning to do so because they don’t know what they’re doing. The in-house team will be bound by the company’s value network to think in terms of adapting books and not in terms of creating functional apps. That’s why they will fail.
Acquiring a development team works better, provided they are kept in a silo, isolated from the rest of the company.
Imagine how empty the web would be if it cost as much to make a website as it does an enhanced ebook app?
The bits that cost money in book apps are relatively easy to identify. As I wrote above, many of these apps have video budgets bigger than some of the Academy Award nominees for best foreign film and most of those nominated for best documentary.
Others use extensive custom designs (every major screen and section is unique) and ignore templates.
Then there’s the immense cost of patching into a print workflow that has been built up with no concern for digital production.
Some add 3D wherever they can.
None of this makes the end result any more interesting. It does make it very expensive.
Apps and websites require new approaches.
Basic things:
Anything that can even remotely be automated should be automated. If your content (text, images, drawing, whatever) isn’t delivered and stored in a format that can be easily transformed and converted, you are handcuffing yourself to whatever idiocy Adobe and Microsoft have decided will pass for ‘strategy’ this week.
Standardising on, at the very least, an intermediary format—whatever you’re going to use for file interchange—for all of your content is a first step. This can be anything from an HTML profile to a database schema.
Always make your decisions as if you were preparing to license it to third parties. Anything that’s going to be awkward for an external developer is also going to be awkward for an internal one. The internal one just doesn’t feel as free to complain.
(Employees who do feel free to complain when there’s something wrong will get reputations as troublemakers and won’t last long in the company.)
If you can’t get your writers and editors to use a minimal markup language of some sort you need to at least require them to deliver all text in a format that can be turned into clean HTML. All projects need to come in a format that can be trivially transformed into HTML. How they get to that HTML doesn’t really matter as long as it’s automatic.
All images and media should be in a central registry. All rights info, copyright, contributors, authorship, and ownership should be in a database somewhere.
Or, at least in an Excel spreadsheet in somebody’s folder. (Thought that really doesn’t scale.)
What most website CMSs do is they use a centralised database for all data, media, and metadata and all text is usually stored in a flavour of HTML.
Ideally, what you want is for all of the text, images, and video you own to be stored and served up via an API so that whoever is developing the website, app, or ebook can simply pull in everything they need programmatically.
If you can, make sure the content is authored so that the producer can pull together whatever version of it is appropriate to their context. That means summaries, abridged versions, tweetable headlines, and the like in addition to the ‘original’ version.
Too many publishers have paid App consultancies a fortune for stupid stuff like data entry.
This is also the only way you can future-proof your business against new digital formats or markets.
If you combine these suggestions (only cheap video, no 3D, less widget-y interactivity, more hypertext, less custom design, more high impact templates, less Word and InDesign, more minimal markup languages and intelligent CMSes) with a text-oriented editorial policy then you end up with something that is remarkably similar to Craig Mod’s Subcompact Publishing.
Something simple is an essential starting point for iterating towards something more complex. You can’t just start off with a complex system. That will fail:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
(John Gall’s Systemantics: How Systems Really Work and How They Fail.)
Don’t do that. Don’t design a complex system from scratch.
That means you should start small. Start by licensing content packages instead of building your own apps or building an API from scratch. Then build a way to automatically turn those packages into APIs. Then do titles that have to be done as APIs. At every stage always do the simplest thing that app developers need to effect their outcomes.
You can only build something complex that works by iterating on something simple that works. Anything else is doomed to failure.