PUBLISHED JULY 2011
by Linda Nix, Founder, Golden Orb Creative —
Books as apps are receiving a lot of attention. But before you decide to produce an app, let alone several apps, you’ll need to understand two things:
- the differences between books produced as apps and books produced as digital files for apps
- the key considerations for deciding whether to go down the book-as-app path
In E-book Formats: The Basics (January 2011), I explained how e-books are digital files designed to be read by specific computer software, sometimes called “apps.” In this sense, one type of software, or app, is designed to read many, many files.
- the Kindle app, which reads e-book files in Kindle (Mobi) and some other formats
- the iBooks app, which reads e-book files in EPUB and PDF formats
- various PDF Reader apps, which read PDF files
- the Stanza app, which reads EPUB files
- web browser apps such as Google e-books, which reads XHTML files
- and many more—you get the idea
Such apps provide a kind of library interface for digital book files (and many apps actually use the term library, though this refers to the part of the software that organizes the file collection for you).
Apps of this sort may include one or more of the following additional features:
- a shopping interface for buying or downloading book files
- bookmarking and other navigational aids
- annotation tools for activities such as highlighting and commenting
- layout and style change tools, for bigger fonts or “night reading mode,” for example
- books sourced from multiple publishers
This last feature is important. It means that any publisher’s books can be read on a particular app if the publisher’s book files are in the correct format for that app.
The other features, which are also important, are part of the reader app, not the book files, which means that a publisher creating files for these apps has to worry only about formats and validation, and not about whether to include specific software features.
The publisher has to produce only one file for each app (not that this is a snap—see Producing E-books Isn’t Easy, which appeared in the March 2011 issue of Independent). It is up to the app developers to make sure an app is available for different platforms and devices.
Books as Apps
Unlike a book for an app, a book as an app is a standalone piece of software. That means it does not provide a way to read lots of book files, nor a way to import new book files. While some apps may be small collections of books, such as an app housing the works of Shakespeare (I have one of these on my iPad; it’s brilliant), those apps are still distinct from the e-book reader apps discussed above.
When a book is produced as an app, rather than as a file to be read within an app, all the features that might need to appear in an e-book reader app, as listed above, need to be developed specific to that app.
This has an advantage: flexibility. Features such as navigation and styling are not limited to the usual e-book set and can be customized to suit specific content. Multimedia can be embedded in creative ways that are not limited by what an e-book reader app may or may not support. Genuine interactivity can be a part of a book app. That is, a book app is not just for reading; it is software that does something.
For example, cookbook apps may have an “Add to shopping list” feature that allows users to select ingredients from a recipe to export for print, e-mail, or a related shopping list app. Textbooks might incorporate sample exam questions with instant marking.
The downside of all this is cost. Instead of spending a couple of hundred dollars producing an e-book file, you are likely to spend a couple of thousand—per platform. Apple’s is not the only app store in town (though it is currently the most lucrative). If you want your book available on many platforms, you will have to produce different versions of your book app: an iOS app (and possibly different versions for the iPhone and iPad if screen size is important); an Android app; and you may want to consider desktop versions for PCs and Macs, as Amazon did for its Kindle app.
Even when developers are producing a base app for export into multiple platforms (by using Adobe® AIR® or a set of custom APIs, for example), they are still likely to charge per app format because of the added complexity and testing involved.
The variety of platforms brings up another main difference between book apps and e-book files. Platforms become obsolete very quickly; if you produce a book as an app, you may have to keep producing the book as an app for years to come, upgrading for new platforms and new versions of platforms. E-book reader apps will also have to be updated, but the updates are the responsibility of the reader app developer, not the publishers of the book files.
In this sense, a book app more closely resembles an edition of a book that will become out of date, with an upgraded version being a new edition. Some publishers might view this as a nice source of revenue if they are able to persuade people to rebuy an app when they upgrade devices.
One other important point: book apps will sit alongside other apps, not necessarily other books. Your customers may not even be looking for a book when they come across your app, so a book app may open up new markets for your content. Conversely, potential customers for the book may still be looking in e-bookstores, so a book app could fail to reach a significant section of the market.
Books as apps open up a whole new world of reading possibilities. App features can be what set a book apart—but you’d better make sure the book stands out for the right reasons. Before embarking on the book-as-app path, ask yourself the following questions.
What kind of book is this? If you want readers to engage with your content in a reasonably traditional linear narrative fashion, then perhaps an app’s features will be more distraction than enhancement. But if your content lends itself to interactivity, hyperlinking, embedded multimedia, and so on, then the flexibility of an app may serve you better than even the most enhanced e-book readers.
What kinds of features would this book app need? Don’t decide to include bells and whistles just because you can. Apart from the cost of developing features that are never used, you should keep in mind size and performance. An app that takes ages to download and is slow when it runs—no matter how pretty it looks or how amazing some of the features are—is not going to be popular. As with all software, an agile approach and user testing will be critical.
How well could I work with the developers? Whether your developers are in-house or external, are they familiar with book content and experienced in working with publishers as well as with app development? Do you know how to brief them, and do you understand their quotes and specifications? If you don’t understand software development, can you find someone you trust who does to help you manage the developer relationship—ideally, someone who also understands today’s publishing environment?
Do I have the budget for development? As mentioned above, a book app will cost at least as much as an e-book, and most likely several orders of magnitude more. As with all software, low-cost app solutions are emerging, so if your aim is to have an app for the sake of being in the app marketplace (as opposed to developing customized apps for specific content), then you may decide app development is affordable.
Do I have the budget for marketing? You won’t be able to rely on your book app being found by book buyers in e-bookstores, so you will have to invest in marketing it through multiple channels.
What is the long-term strategy for the book? Do you want to produce a book file once to be read (and bought) by people for years to come, as should be possible for books produced in XML? Or do you want to produce new “editions” (updates) every few years, as you will likely need to do for a book app?
More Things to Think About
This very brief introduction to books as apps hasn’t even touched on some other important issues, such as integrating book apps into metadata systems. Should book apps have ISBNs? Should they be registered with the Library of Congress and other legal deposit libraries? Who owns the intellectual property in the book app—the original author, or the developer who creates features specific to that book?
The fact that such issues are unlikely to be resolved any time soon is no impediment to book app development for those with the creativity and resources willing to go down this path—nor should it be.
But I’m not convinced that books as apps are for everyone. In an industry where so many traditional publishers and new entrants are struggling with e-book formats, platforms, business models, and metadata, producing books as apps may be an unwelcome (and unprofitable) distraction. If struggling with change sounds like you, I hope this article will help you see whether you really need to be spending time and resources right now on producing your books as apps.
Linda Nix has more than 20 years of experience in publishing for print and online, across a range of production, editorial, marketing, IT, and business roles for small and large organizations in Sydney and Seattle. Drawing on her experience in online sales platforms and multiformat production systems, she recently began consulting under the name Golden Orb Creative Services, a move allowing her the freedom to publish her blog Gossamers. To reach her, email firstname.lastname@example.org.