Books as apps are receiving a lot of attention. But what is a book app? And is it a good idea? This article explains the differences between books produced as apps and books produced as digital files, and outlines the key considerations in deciding whether to go down the book as app path.

Books as digital files for ebook reader apps

In a previous article, ebook formats: the basics, I outlined how ebooks are digital files designed to be read by specific computer software, sometimes called “apps”. In this scenario, one type of software or app is designed to read many, many files. Examples include:

  • the Kindle app, which reads ebook files in Kindle (mobi) and some other formats;
  • the iBooks app, which reads ebook 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 eBooks, which reads XHTML files;

and many more – you get the idea.

Such apps provide a kind of library interface for your digital book files (and many apps actually use the term “library”, though this refers to the part of the software that organises the file collection for you). Such apps may also include one or more of the following additional features:

  • shopping interface to buy or download new book files;
  • bookmarking and other navigational aids;
  • annotation tools, such as highlighting and commenting;
  • layout and style changes (eg bigger fonts, “night reading mode”); and
  • books sourced from multiple publishers.

This last point is significant: as long as publishers’ book files are in the correct format for the app, any publisher’s books can be read on the app. The other points collectively are also important: these features are part of the reader app, not the book files, which means publishers only have to worry about formats and validation, and not about whether to include specific software features. The publisher also only has to produce one file for each app (not that this is easy – see previous article on ebook production). It is up to the app developers to make sure the app is available for different platforms and devices.

Books as stand-alone apps

A book as an app is a stand-alone piece of software. That means it is not an app for reading lots of book files, nor one that allows the import of new book files. While some apps may in fact be a small collection of books, such as an app housing the collected works of Shakespeare (I have one of these on my iPad; it’s brilliant), such apps are still distinct from the ebook 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 ebook reader app, as listed above, need to be developed specific to that app. This has the advantage of flexibility – features such as navigation and styling can be customised to suit the actual content, and are not limited to the usual set of ebook features. Multimedia can be embedded in creative ways that are not limited by what an ebook reader app may or may not support. Genuine interactivity can be a part of your book app. For example, cookbook apps may have an “add to shopping list” feature that allows you to select specific ingredients from a recipe to export for print, email or a related shopping list app. Textbooks might incorporate sample exam questions with instant marking.

The downside of all this is cost and effort. Instead of the couple of hundred dollars spent producing an ebook file, an ebook app is more likely to set you back a couple of thousand – per platform. Apple’s is not the only app store in town (though 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 their Kindle app. Even developers who are producing a base app for export into multiple platforms (for example, by using Adobe® AIR® or a set of custom APIs) are still likely to charge per app format because of the added complexity and testing involved.

The question of platforms brings me to another main difference between book apps and ebook files. Platforms become obsolete very quickly; if you produce a book as an app then you may have to keep producing the book as an app for years to come, upgrading for new platforms and new versions of platforms. Ebook reader apps will also have this problem, but the upgrades 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, with an upgraded version being a new edition – some publishers could view this as a nice source of revenue, persuading people to re-buy an app when they upgrade devices.

Finally, remember that 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: a book app may open up new markets for your content. Conversely, potential customers might still be looking in ebookstores, so you could miss out on a significant section of the reading market.

Things to consider before producing books as apps

Book apps open up a whole new world of reading possibilities. App features could be what sets your book apart – but you’d better make sure it stands out for the right reasons. Before embarking on this path, ask yourself the following questions.

1. What kind of book are you producing? 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 be better than the limitations of even the most enhanced ebook readers.

2. What kinds of features does your book app need? Make sure you don’t 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.

3. Are you comfortable working with developers? Whether your developers are in-house or external, are they familiar with book content and working with publishers as well as with app development? Do you know how to brief them, and do you understand their quotes and specifications? A former colleague who now works at a major publishing house related how their commissioning team recently sought quotes from three different developers for a book app; each quote came in at a vastly different amount from the other two, and the team could not work out why. If you don’t understand software development, find someone you trust who does to help you manage the developer relationship – ideally, someone who also understands today’s publishing environment.

4. Do you have the budget for development? As mentioned above, book apps will cost at least as much as an ebook, 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 customised apps for your specific content) then you may find app development affordable.

5. Do you have the budget for marketing? You won’t be able to rely on your book app being found by book buyers in ebookstores, so you will have to invest in marketing your book through multiple channels.

6. What is your 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” (upgrades) every few years, as you will likely need to do for your book app?

Some other issues

This very brief introduction to books as apps hasn’t even touched on some of the other 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 developer who creates features specific to that book? 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 ebook formats, platforms, business models and metadata, books as apps must seem an unwelcome distraction. If this sounds like you, hopefully this article has helped clarify whether you really need to be spending time producing your books as apps.

© Copyright Linda Kythe Nix 2011. All rights reserved.