• Print

Open Question: Standalone iPhone Ebooks vs. E-Readers

Ebooks as iPhone applications started as a novelty/workaround, but the technique is now being used by Houghton Mifflin for a full-fledged digital rollout. From Wired’s Epicenter blog:

The publisher recently partnered with a design and development company called ScrollMotion to launch a series of bestselling in-copyright e-books for the iPhone where each title is its own app and a reader is bundled with each download. Thus the iPhone itself, despite the small screen and lack of E Ink technology, becomes the reader.

On the other side, the recently released Classics app uses the iPhone’s software update to load new ebooks, and a number of publishers (including O’Reilly) deliver ebooks to the iPhone and iPod Touch through the Stanza e-reader.

Both methods have their pros and cons (e.g. storage limitations, selection, interface), but I’d like to know what TOC readers think: Which format holds the most promise? Which do you use?

tags: , , , , ,

Comments: 11

  1. Bundling a book as an individual application is an attractive option to many publishers because they can take advantage of the App Store’s nice feature set on a book-by-book basis: individual descriptions, cover art, ratings & reviews, a no-fuss deployment mechanism, and searchability from within iTunes (where users are already accustomed to searching for digital media by title or author). The down-sides are that Apple takes a decent sized cut of the revenue (30%) and the fact that applications are reviewed on an individual basis (regardless of whether the application is a book or not), and the review process can sometimes be lengthy.

    From a reader’s perspective, the book-as-application approach can be problematic, because there is little functional unity between the different reader frameworks (the software that actually renders the text to the screen), and there can be no shared user settings between different applications. So while Book A distributed in Framework A might display the text on a page-by-page basis, Book B in framework B might display it as continuous vertically scrolling text. And maybe Framework A allows you to change the background color of the text, Framework B might not have the ability to change that option. In any case, once the user sets up Framework A to display the text just the way they like it (Georgia font, point size 13, background color cream, foreground color blue, justified text with British English hyphenation rules), they will need to go through the entire customization process for each individual book using a potentially different user interface. This can lead to confusion and frustration.

    Library-based book readers (i.e., applications that are designed to enable the acquisition and management of multiple books), on the other hand, do enable the user to set up their reading environment once and have it apply to all their books. Where they become tricky is content acquisition, which can involve cumbersome processes (not made any easier by the inability for third party applications to use the iPhone’s USB dock connector). Couple that with the DRM requirements imposed by many publishers, and the technology required to have a smooth and user-friendly content acquisition process because considerably more difficult to implement than just bundling the book as a stand-alone application.

    In the interest of full disclosure, I work for Lexcycle (the makers of Stanza). However, since we make both a library-based reader and a reader framework for bundling books as individual applications, I’m not particularly biased one way or the other.

  2. I prefer one reading application that lets me load books onto it, as opposed to individual book applications. Currently, I’m using eReader by fictionwise. I like how the books are organized and they give me several options on formatting the text.

    Personally, I don’t like the idea of individual book apps because it would clutter up my iPhone. Also, it appears that Apple has limited the iPhone to 148 apps (this is being reported on several blogs this morning).

    However, regardless if one prefers individual book apps or a ebook library app (such as Stanza or eReader), I think the one thing holding ebooks back from becoming even more popular is the evil DRM. Once publishers can get past this, I think we will see ebooks really thrive!

  3. I use my iPhone and primarily Stanza, though I have other reader apps on my phone.

    I am at this point very unlikely to also purchase a separate ebook reader, first, because the iPhone is far more than sufficient for the purpose, and second because readers are MUCH too expensive.

    However, I think you may be asking the wrong question, at least in part. As one of the class of people who read eBooks on a handheld device, I can tell you that price is by far the biggest factor in my decisions about what/where to read. I was recently quite excited to see a recent release I’ve been looking forward to reading. The eBook version was $26.00. The same list price as the hardback, which is available from Amazon for $17.00. In other words, I can buy the print version, including shipping, for less than the eBook version. And without DRM, too. So no, I did not purchase that book to read on my iPhone.

    For people who don’t all ready have a device, where’s the incentive to spend a lot of money (too much money) on a device only to be ripped off on the books, too?

  4. > Ebooks as iPhone applications
    > started as a novelty/workaround

    i don’t know what you mean by this.

    bundling of the viewer-app-plus-book,
    according to the link you provided, was:
    justfied by the original developer like this:
    > Developers can only distribute applications
    > through the App Store; there is no way to
    > distribute data files like ebooks. Therefore,
    > it made sense to me that each book
    > had to be a complete application.

    but subsequent programs have proven that
    the viewer-app can download books just fine.

    so i suspect the _real_ reason is that it made it
    very convenient to collect a fee for _each_ book,
    rather than a one-time fee for the viewer-app…

    i don’t have any figures, of course, but i’d guess
    that that developer has suffered a decline in sales,
    since he was basically extracting far too much cash
    for each of the public-domain titles he was selling.

    financial considerations aside, the bundling of the
    viewer-app with the book itself has some benefits,
    and some costs. whether or not it is “a good idea”
    tips on the size of the program relative to the data,
    _and_ how many times the duo will be downloaded.

    it’s hard to know the filesize of an iphone application,
    in most cases, so it’s hard to answer the first question.

    as for the second question, for “appengines” books,
    each duo is downloaded once, barring any updates,
    so that’s not too bad. but if you imagine having, say,
    400 books, and the program was revised quite often,
    the re-downloading process would be cumbersome.

    for the “classics” app, however, we do know the size,
    and we know that it is _big_ — over 10 megabytes —
    since itunes won’t let us download it except via wifi…

    moreover, since its entire catalog (rather than 1 book)
    _must_ be downloaded each time the app is upgraded
    _or_ books are added to its catalog, we know for sure
    that this bundling is a terribly inferior way to proceed…

    the one positive thing is that its library consists of just
    one file, so is easily summoned. the appengines books
    are each separate apps, so each one must be set up and
    executed independently, which is a big hassle, especially
    since each book takes up a space on your iphone screen,
    meaning that a library of hundreds of books is clumsy…

    (plus i’d forgotten what brad notes, which is the iphone
    only has “slots” now for about 150 different programs…
    even if apple increased that in the future, it’s still clumsy.
    we need to allow people to carry thousands of e-books.)

    but either way, it appears that the combined model sucks,
    at least under present conditions, unless they changed…

    so it looks like the “library” model — where the program
    and books are separate — is the best one for the iphone.

    i haven’t yet mentioned the _benefits_ of combining them,
    so let me do that now. a merged file lets you _customize_
    the program for a specific book, if it has special properties
    most other books do not have. it also ensures each book
    will not “break” on a regression if the program is upgraded;
    in other words, if it worked originally, it continues to work.

    but again, these benefits probably don’t outweigh the costs,
    so the “library” model is best. (and um — quite honestly —
    what houghton mifflin harcourt is doing is just immaterial.)

    that doesn’t mean that the library model, as implemented,
    couldn’t use some improvement, however, because it can.

    specifically, the process of finding and downloading each
    book _separately_ is rather cumbersome. as far as i know,
    there’s no good reason you couldn’t download hundreds or
    even thousands of e-books with the push of a single button.

    nonetheless, i give stanza big credit for making a very, very
    good viewer-program — not _great_, but very, very good —
    one that can grab books from several e-libraries out there…

    the promise of e-books is not just that you can carry a book
    in your pocket, it’s that you can carry a _library_ in there…


  5. An added benefit of all this–regardless where the “book/app” model is relative to something like Stanza or eReader–is the attractive possibility of adding even more functionality to the iPhone (and with it possible emulation on the BlackBerry Storm by some means) that makes it a more attractive investment than another device one has to store, carry, and charge. Certainly the trouble of e-readers is minimal for its target market–avid readers to whom having a thousand easily-accessed books is an asset worth the price–but Sony, et al would be foolish to ignore this potentially significant siphon from the consumers to whom their e-readers would appeal. (As Carolyn said above, the iPhone is sufficient for the purpose of viewing an e-book, which is all some people ask.) It doesn’t help that iPhones are far more trendy than an e-reader, regardless of whether or not the former is better for reading e-books.

    This leads to what I’m excited about: improved apps on the iPhone and the reflexive product-refinement by e-reader developers/manufacturers. In the present economy, I fail to see anything wrong with some healthy competition.

  6. I’m glad I mulled this over a bit before posting. My initial reaction was that I categorically prefer e-reader-delivery on iPhone/iTouch through something publisher-independent like Stanza to standalone book-level apps. But then some exceptions began to come to mind. It really comes down to that distinction between books that are read and books that are used.

    For example, I would cheerfully purchase travel guides as stand-alone Apps, if they were cleverly constructed to get the most out of the platform. Keeping an iPhone’s data connections going full-time isn’t always practical for someone who is travelling internationally, so there would be real utlity in having that kind of content stored locally. Having updates delivered through the App Store would be a nice bonus.

  7. > For example, I would cheerfully purchase travel guides
    > as stand-alone Apps, if they were cleverly constructed
    > to get the most out of the platform.

    right. this is what i was talking about when i said that
    the merged approach allows you to “customize” the app
    for the needs of a specific book, in this case a travel guide.
    it’s not hard to imagine how that customization can be cool.

    but that’s a slippery slope. in customizing a “travel guide”,
    all of a sudden you’re in brand-new territory, where you’re
    competing against full-fledged “travel-guide programs”,
    like “aroundme”… since those travel-guide programs can
    update themselves dynamically, use the person’s location,
    and direct the person to entities in over a dozen categories,
    ranging from apple stores, banks, and bars, to supermarkets, taxis, and theaters, you might find print-based travel-guides
    are far too static and old-fashioned for a majority of users…

    that’s one type of problem if a dinosaur tries to be a mammal.

    > Keeping an iPhone’s data connections going full-time
    > isn’t always practical for someone who is travelling
    > internationally, so there would be real utlity in
    > having that kind of content stored locally.

    if i’m not mistaken, stanza and ereader do indeed store
    e-books right on your machine, so you don’t need to be
    net-connected to read them after you download them…


  8. I have used Stanza, Classics and e-Reader for the iPhone. Of these, I would have to say that Stanza is the best platform, although I think Classics is pretty sexy and could be a real contender if they made it more customizable (i.e., type size, contrast, etc.) The bigger issue is getting new content from multiple publishers in one source, when that is provided and I can do it wirelessly without being tied to one retailer (and one price point) then I will be happy.

  9. When I first purchased my iPhone, I bought a number or O’Reilly Stand-Alone E-books for it and liked them very much. Unfortunately I am having to give up my iPhone and need another way to read these books. They represent a significant investment and I need them for my professional use (Linux programming). Is there any way to read them other than with an iPhone/iPad/iTouch??

  10. @John, you can export the ePub file from your standalone ebooks; that ePub will be readable on multiple devices and with a variety of readers.

    You can find instructions for exporting the ePub at http://oreilly.com/ebooks/oreilly_iphone_tips.csp#extracting_a_pearl