This article originally appeared in TidBITS on 2010-07-25 at 2:00 p.m.
The permanent URL for this article is: http://tidbits.com/article/11459
Include images: Off

Take Control’s Problems with Apps and Docs in iOS

by Adam C. Engst

Until the iPad came out, we didn’t receive many requests to read our Take Control ebooks [1] 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 [2]” (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:

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:

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:

[image link] [6]

On the iPad, we learned that EPUB files can be opened in Stanza [7], GoodReader [8], BookShelf [9], and CloudReaders [10], 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? [11],” 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.

[image link] [12]

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.

[1]: http://www.takecontrolbooks.com/
[2]: http://db.tidbits.com/article/11430
[3]: http://db.tidbits.com/article/11465
[4]: http://tidbits.com/resources/2010-07/Download-Failed.png
[5]: http://tidbits.com/resources/2010-07/Open-In-for-PDF.png
[6]: http://tidbits.com/resources/2010-07/Open-In-for-Zip.png
[7]: http://itunes.apple.com/us/app/stanza/id284956128?mt=8&at=10l5PW
[8]: http://itunes.apple.com/us/artist/good-iware-ltd/id289191291
[9]: http://itunes.apple.com/us/app/bookshelf/id284934036?mt=8&at=10l5PW
[10]: http://itunes.apple.com/us/app/cloudreaders-pdf-cbz-cbr/id363484920?mt=8&at=10l5PW
[11]: http://db.tidbits.com/article/11378
[12]: http://tidbits.com/resources/2010-07/iOS-download-warning.png