Publishers are looking to create stand-alone e-book applications for the iPad. Rather than simply creating an ePub-formatted text to be purchased, stored, and read in the iBooks app, the idea here is to go ignore the ePub standard in order to bundle extras with the book. They’d provide you with an individual computer program to be installed and run just to read a single book. In the case of Penguin Books:
We will be embedding audio, video and streaming in to everything we do. The .epub format, which is the standard for ebooks at the present, is designed to support traditional narrative text, but not this cool stuff that we’re now talking about. […] So for the time being at least we’ll be creating a lot of our content as applications, for sale on app stores and HTML, rather than in ebooks.
The enhanced Baldacci e-book is one of several projects Hachette will release over the coming weeks, including a NASCAR-oriented app, a synchronized text/audio edition of Michael Connelly’s crime novel Echo Park, and a standalone app version of David Foster Wallace’s thousand-page magnum opus Infinite Jest. “One reason the book is so famous is because of the footnotes,” says Maja Thomas, senior VP of Hachette Digital. “We thought, wouldn’t it be great if, when a footnote appears, there’s a symbol in the e-version of the text, and if you tap on it, you can go right to the footnote, and then tap back into the text at any time.”
Even Random House is pushing these stand-alone apps as a class of books, which they call Book and Beyond.
All of this is both a bad idea on many levels and largely unnecessary.
Imagine that, in addition to listening to music in iTunes (or Windows Media Player, or whatever), there were some albums that you had to install. When you wanted to listen to those albums, you’d need to fire up your special Thriller, Dark Side of the Moon, or Rubber Soul program. (Remember “Enhanced CDs,” from the late nineties? Are you getting a lot of use out of yours?) Would you listen to those albums more often, or less often? How many albums do you own? Would you want to install a program on your computer for every one of them? (And, if you did, wouldn’t you want a program to manage them? “iTunes,” you might call it?) Or imagine that some websites could only be accessed by downloading, installing, and running a special program. Want to check scores on ESPN’s site? Run the ESPN program. Looking for something on Amazon? Double-click on that Amazon application. Would that constitute an improvement in your life, or an obstacle?
What about in a couple of years, when Microsoft or Sony or Amazon releases a whizzy new e-book reader that you want to upgrade to after your iPad gives up the ghost? You can take your ePub files with you to that new reader … but your iPad-only, collectors-edition Infinite Jest application won’t run on your new device. You’ll have to buy those books again to read them.
From the perspective of consumers, it’s tough to envision how stand-alone e-book applications are better than simply reading an e-book in your e-book software.
The situation isn’t much better for publishers. Creating an ePub file isn’t particularly challenging (it’s basically a website, each chapter its own web page), with your average novel requiring maybe a few days’ work for a website developer of average ability. Creating one or more stand-alone e-book applications—one for each popular e-reader—for every book? As we programmers say, that’s nontrivial: expensive, time-consuming, and prone to bugs, requiring an approval process from some manufacturers (including Apple—which can be capricious), meaning that there’s always the possibility that all that work could be for nothing. It is an order of magnitude more complex to developing an application rather than an ePub file.
Most of the extras that Penguin intends to bundle with their books can be included with an ePub. Excised passages and research photos can be included as additional chapters, and video and audio can even be embedded by a moderately clever developer. (Hatchette’s vision of DFW-style footnotes can be realized with even the crudest of e-books.) The very modest benefits of a stand-alone application are overwhelmed by the drawbacks. Any shortcomings in the ePub standard are cause for publishers to bring their considerable resources to bear in improving that standard, rather than simply bailing on it. Eschewing stand-alone e-book applications for ePubs will save money for publishers and, more important, make customers much happier in both the short and the long run.
9 Comments
Except that DRM prevents consumers from legally taking advantage of this mobility.That’s absolutely right, insofar as DRM is used, but DRM is neither inherent or necessary. Although the iTunes Music Store started with DRMed tracks, at the demand of labels, Apple was able to persuade labels to drop that demand, and now the bulk of the tracks for sold via iTMS are unencumbered, as straight MP3s. Amazon.com likewise sells only MP3s. If there’s any reason why the same pattern won’t repeat itself with e-books, I don’t know about it.
I’m confused by Hatchett’s footnote remark; as though this is some amazing new feature. All the books I provide at epubBooks.com use linkable footnotes and have done so since I started realsing them.I’m with you, Mike. That’s both mystifying and discouraging.
The final editing needed was to set up links for the footnotes. As I’m storing the footnotes in a separate file I marked up the entry in the spine with linear=”no” as this should be considered an “auxiliary” file. Now all that was needed was to add the filername to the a tag in the footnotes.xml file, which in this case became chapter001.xml#fn-place-1 and In the chapter001.xml file I added a link to the footnote file, footnotes.xml#fn-1.To somebody enthusiastic about providing semantically-pure data, no doubt it’s a bit horrifying to provide data that looks right but has no meaningful metadata behind it. (i.e., blockquotes piled three deep.) But the alternative–moving to a stand-alone application–means that no metadata is exposed, so providing something visually accurate but metadata-poor is surely a better route.
Albums, particularly the ones you have listed, were designed to be listened to as a unit, not as a broken up list of songs.And there’s nothing preventing you from listening to them as a unit in any MP3 software.
How many albums do I own? Over 1,000. Would I want to install an application for each of them? Yes, memory is cheap particularly if we can offload the “none core” albums to memory cards. Wouldn’t you want a program to manage them? (ITunes?) Yes I would, but not ITunes. Just something that would let me browse the collection and “chain together” albums to play one after the other.Congratulations–you’ve just reinvented the album and iTunes and called it something else. :)
To answer your website as app questions: I do exactly that. If I want to check the weather on Weather.com, I utilize the Weather.com app on my phone. If I want to read the news on Thompson-Reuters, I use there app to do so.But you haven’t abandoned the web browser, have you? The notion of having an individual program for every single website that you might ever want to visit is ludicrous. You would need thousands of them. Ditch your browser on your phone. Install apps for everything you want to do on the internet. Let me know how that goes. :)
As for obsolescence, what guarantee is there that ePub will still be a standard that anyone is supporting in the next 5 years. Haven’t we seen enough “standards” rise and fall to be just a little skeptical about the longevity of any one of them? If you are looking for a standard with a long history of acceptance and improvement pick PDF.There’s no guarantee of anything in life, but the benefit of EPUB is that it is an open standard, making it pretty close to a guarantee. If I want to do something new with Flash, I need Adobe’s permission. PDF used to be a closed standard, like Flash, but it was opened up eighteen months ago. The difficulty with PDF is that it is impractical for use on most devices for a variety of reasons, not the least of which is that it is created around the concept of faithfully reproducing a page in a single format. It has no concept of rescaling text (as all e-readers support) without rescaling the entire page outside of the bounds of the device’s screen. Design and content are one and the same. Without divorcing those two, such as in the HTML/CSS division, the format isn’t sufficiently flexible to be of much good on e-books. It’s fundamentally wrong for e-books. Any publisher can use the EPUB format without paying a dime to anybody, knowing that’ll work on most any e-reader, no strings attached. That’s a very powerful force in the market. The fact that Apple has embraced EPUB to the exclusion of all other formats shows how dominant EPUB has become.
As for portability, it would be just as easy for a device creator or third party creator to provide backward compatibility or a “reader” for Flash or PDF (and I will wager that most book apps will be written in one or the other) as it would be for them to provide one for ePub.Nope, not for the previously outlined reasons. Flash and PDF are awfully complex. EPUB is very, very simple, with dozens (hundreds, probably) of existing tools to manipulate, update, batch modify, and otherwise work with its contents. If I had to transform 1,000 EPUB files in some arbitrary way (increase the size of images, add a few new CSS rules, and update the HTML to XHTML 1.0 Strict, for instance), I could write some code to do that in an hour or two. Doing that for Flash or PDF would present a significant challenge to any programmer.
As for why people might want books as apps rather than books in a standard reader formats: Epub, and all formats that allow resizing/re-flowing, of text are by their nature horrible: typographically and for protecting content. Typography is a mature art that has determined certain “rules” for how to make text not only legible but enjoyable to read.EPUB is silent on typography, as it well should be—that’s a function of CSS and of the rendering engine (i.e. WebKit on the iPad). You and I might look at a page of text on the Kindle or iPad and cringe at the widows and orphans, the word spacing resulting from excessive justification, the lack of hyphenation, etc., but face it: the vast majority of consumers don’t care and won’t consciously notice. This sort of aesthetic matter has no impact on buying decisions and, thus, the market. Apple will no doubt add a hyphenation dictionary, propose some EPUB extensions to provide typographic hinting functionality for content creators (as an open format, such modifications are easy), and typography will be improved enormously in 12-24 months.
Just try word spacing or letter spacing or kerning characters in HTML. It can be done but only by completely abandoning the “nature” of the ePub format.That’s not true. Letter spacing (that is, tracking) and word spacing have been functions of CSS for a decade now, using the “letter-spacing” and “word-spacing” properties. EPUB happily supports them. Kerning is a CSS3 Web Fonts proposal, liable to find its way into CSS (and, thus, EPUB) within months, although only for those fonts that include kerning data, of course.
So while it is true that “most of the extras that Penguin intends to bundle with their books can be included with an ePub.” It is also true that the content could then be easily misappropriated. It is much more difficult, though not impossible, for most people to un-compile an app than it is to unzip an ePub.That’s what DRM is for. Every book that Apple sells is wrapped in DRM, making impossible the scenario that you describe.
It can be done in ePub with javascript and/or title attributes or some combination of them but this, again, violates the spirit of the ePub standard.I can’t see how it violates any spirit. EPUB is HTML. JavaScript popups have been viable in HTML since…well, I remember creating them using Mocha in Netscape 2. Mocha began JavaScript, and Netscape ultimately begat Firefox, so not much as changed. If I were doing this, I’d include the footnotes in an endnote DIV at the end of each chapter, and then use JavaScript to suppress their display at the end and summon them by ID as a floating DIV when somebody selects the footnote. That’s totally within the spirit of HTML and EPUB.