Hide full article
Until the iPad came out, we didn't receive many requests to read our Take Control ebooks on the iPhone and iPod touch. But once the iPad appeared, the email from readers requesting this capability started to pour in.
What We Want, and Why We Can't Have It -- If you're shopping for an ebook, it should be easy for you to browse a Web-based catalog, pay via an online cart, and download your new ebook to your device, whether that device is a laptop or desktop computer, a new iPhone 4, an iPad, an older iPhone or iPod touch, or maybe an Android phone or other device.
And, in the Take Control Web site and cart, all of that is possible... except downloading of the files. We haven't yet seriously looked into the Android and other handhelds, but we have recently spent quite a lot of time learning how we can make it possible to download to an iOS device and investigating how iOS makes the connections between apps and documents. This investigation prompted Matt Neuburg's article, "Apps and Docs in iOS" (15 July 2010). If you haven't done so already, go read Matt's article - what I say next may not make sense without that background.
Now think about what Matt says in relation to a publisher offering an Internet service that provides downloadable content to iOS device users, such as a purchased ebook or a software manual. The Take Control series, as an example, faces several hurdles:
iOS offers no centralized file storage area, so any downloaded file would live in only one app, or, if that app could share with others, multiple copies could be spread among multiple apps. That could be confusing for users, who would likely then turn to us for help.
iOS needs to support Zip files. We distribute our ebooks as zipped PDF files, not just to reduce file size, but also because it ensures that when you download the file, you really download it, as opposed to displaying the PDF in your Web browser. Otherwise, someone could become confused by closing a PDF-displaying browser window and "losing" the ebook. Although some iOS apps can handle Zip files, none of Apple's own apps can. Plus, there's no programmatic way - either on the iOS device itself or on a Web page - to know before a link is clicked if a user has an app like GoodReader that can handle Zip files, so we can't even sniff the presence of a Zip-handling app and change the download page accordingly.
Although our cart doesn't have a feature for presenting iOS-using customers with straight PDFs at the end of the shopping process, such a feature would be fraught with problems. A straight PDF download might work in iOS 4, under which Safari presents a normal Open In dialog, but in iOS 3.2 on the iPad, Safari displays the PDF but doesn't let you open it in any other app to save it. Navigate away from that page, and the PDF disappears. And since the download URLs in our cart are good for only a limited time, you wouldn't be able to get that PDF again. That's not a good user experience.
Luckily, as we were trying to figure out a better alternative for iOS users, we were also building our Take Control account management system. At some point we had a brainstorm - iOS users could download their books when they were logged in to our Web site. We have PDF versions of all our ebooks, and EPUB and Mobipocket versions of many of them. You could log in to your account and then view the PDF version of one of our ebooks in Safari or download into GoodReader, which offers better ebook-reading features. And with PDF, that's easy and is working now.
But what about EPUB? Apple's iBooks app can display EPUB files copied into the Books category in iTunes, but it turns out that iBooks does not register itself as being able to open files with the EPUB UTI. Tap a link to a .epub file on a Web page loaded in Safari and another app might offer to open it, but iBooks won't. Worse, if the user doesn't have any app that can open an EPUB file, Safari merely reports "Download Failed: Safari cannot download this file." Also not a good user experience.
Why Not Use the iBookstore? An answer to this problem is to upload our ebooks to the iBookstore, and in fact, we've done that with a number of our titles (search for "Take Control" from within iBooks). However, we don't consider the iBookstore a complete solution, for a number of reasons:
We want the autonomy of running our own site so we control the shopping experience, including offering bundle discounts and sales like this week's 50-percent-off sale (see "Take Control Sale: 50% Off to Celebrate Account Management," 26 July 2010).
Working with the iBookstore is slow. It takes roughly two weeks for a book to be approved for sale, and even once it has been approved, changes take anywhere from a few days to a week.
All books in the iBookstore must be in EPUB format, even though iBooks now supports PDF. Although we have converted many of our PDF-based ebooks to EPUB, the PDF versions look and work a lot better on the iPad (EPUB is better for the small screen iPhone and iPod touch).
The iBookstore is a black box, accessible only via iBooks. There's no way to link to a book in the iBookstore from the Web, as is possible with the iTunes Store and the App Store.
Apple takes a 30 percent cut of sales from the iBookstore, and while we don't begrudge them that, we'd prefer to sell directly from our site, where our transaction costs are lower.
If you purchase one of our ebooks through the iBookstore, you must create your Take Control account manually, or, if it's already created, add your book to it manually. Account creation and population is handled automatically for orders through our cart. We give free and generously discounted updates to many of our ebooks; some of that won't be possible for iBookstore customers.
The iBookstore has a nice layout, but it's not ideally suited to the needs of our ebooks and customers.
Further, other organizations or individuals may wish to make a few documents available for download to an iOS device in an informal manner, but not so informal that they toss their documents to the winds of the current iOS approach. Brochures, posters, course catalogs, newsletters, and so forth, for instance, don't belong in the iBookstore.
Documents in the Dark -- So, assuming Internet-based file serving of ebooks is something we want to roll ourselves, what would be a good user experience, since nobody can predict in advance what file types a particular iOS device can open in which apps? To explore this question, I created a simple Web page that linked to a PDF, an EPUB, a Mobipocket file, and a Zip file, and we tested what happened when we tapped each of those links in Safari on different devices. Then, to see if the results were different outside of Safari, Matt wrote a tiny app that contains sample documents in each of these formats and displays the Open In dialog when the user taps an associated button.
Alas, our results were all over the map. The iOS 3.2-based iPad reacted somewhat differently than the iOS 4-based iPhones, and each device offered different options for opening any given file type based on which apps were installed on it. This is, in fact, how we learned that iBooks cannot open an EPUB via the Open In dialog, and that Safari in the iPad's iOS 3.2 doesn't offer an Open In dialog for PDF, while Safari in iOS 4 does. So, while Safari can open linked files of various types and potentially hand them off to other apps, one of three things will occur:
If no app on the iOS device can handle the file type, Safari displays a Download Failed dialog.
If the file in question is a PDF, Safari loads it and displays it, and, if you're in iOS 4, it also shows native Open In buttons (below left). If there is only one app that can handle a PDF, such as iBooks, you'll see a single Open In iBooks button. If you have multiple apps that can handle PDFs, one will be the default (I'm guessing now that it's the most recently updated), and the full set (below right) will be displayed if you tap the Open In... button.
If the file isn't a PDF, but there's an app that can handle it, Safari downloads it and displays an unusual Web page-based "dialog" that shows either a specific Open In AppName button, or both that and an Open In button (below left) that, when tapped, shows the list of available apps for that file type (below right).
The user experience here isn't good either. This "dialog" isn't a real Web page, in that you can't scroll it vertically on an iPhone or iPod touch screen, and its buttons are below the bottom of the page and out of tapping range. Plus, if you have zoomed the Web page containing the source link, the resulting page for the "dialog" is also zoomed, with the effect that the dialog is sometimes completely out of sight. If multiple apps can handle a file type, the icons that Safari shows are almost always mixed up between the apps. Finally, I've had to terminate Safari manually in at least one case - dealing with that dialog froze the app.
On the iPad, we learned that EPUB files can be opened in Stanza, GoodReader, BookShelf, and CloudReaders, though only Stanza can actually display the EPUB file. We also learned that Bookshelf can open and display a Mobipocket file. BookShelf, CloudReaders, and GoodReader all claim to be able to open a Zip file, but only GoodReader can. Lots of apps can open PDFs, including iBooks and GoodReader. (In our initial tests on an iPhone and iPod
touch, GoodReader wasn't showing up in the Open In dialog at all, since it hadn't at that point been updated for iOS 4. This is yet another area where apps must be rewritten and recompiled to deal with the ever-evolving iPhone system - see "What is Fast App Switching?," 23 June 2010.)
For people like us, who try to give reliable, concrete directions, this situation is maddening. At Take Control, we want to provide a service to our readers, supplying an ebook via the Internet and helping the user open it in some appropriate app. But we're having trouble doing that because there's no way of predicting what will happen on any given user's device.
It would be great if we could write an iOS app or code a Web page that checks what a user's options are and says, "You have an app that can open an EPUB, so shall we download the book as an EPUB?" But we don't see any way to learn what the user's options are. We can't find out what apps the user has that can open a certain type of document, and there's no central registry telling us even what apps exist that can open a certain type of document. If, on the other hand, we just provide a URL to the ebook and let the user open it in Safari, we've ceded control to Safari, which might tell the user that there's no app that can open this document. Now the user is confused, stymied, and probably mad at us.
Interim Solutions -- What have we done? Two things. First, we've added a blue-colored note to the first screen of our cart when it's loaded from an iOS device, giving customers advice on how to proceed once they finish ordering.
Second, when you visit your Take Control Account page from an iOS device, we focus the available links on downloading the PDF file for each purchased ebook. One link downloads the file in Safari; the other downloads in GoodReader, by using the ghttp: scheme that GoodReader alone understands. We recommend the latter, since it's a better experience. (In fact, it downloads the zipped PDF, which GoodReader can expand, resulting in the full book title being displayed in GoodReader, rather than the filename of the PDF.)
We'll be evaluating these decisions (and the specific interfaces we use) regularly, and if we come up with something better, we'll implement it. We're definitely feeling our way at this point, and are open to suggestions.
Right now, we don't let readers download the EPUB and Mobipocket versions of our ebooks directly. They're accessible only as zipped archives from your Take Control account, and only from a desktop or laptop computer. That's because, as noted above, iBooks can't open EPUB files from a link yet, leaving only Stanza (EPUB) and Bookshelf (Mobipocket) as the apps that could handle those links. However, we plan to make it possible to download those files within iOS in the future, once the apps (iBooks in particular) catch up.
(In case you were wondering, we don't sell a bundle of the PDF, EPUB, and Mobipocket files because we don't want to delay publication until EPUB and Mobipocket conversion is done, and we don't want users to get different things depending on when they download.)
Overall, the moral of the story is that until Apple makes the whole business of apps and documents more rational and open in iOS, every document type will have to be dealt with individually, on a case-by-case basis, with a lot of head-scratching and frustration for anyone who wants to offer documents for download from the Internet. Document types are a good idea, obviously, but Apple needs to loosen the wraps and make this a better experience for users and developers alike. Otherwise, while we don't want to say that what Apple has provided is worse than nothing, it's darned close.
