The age of the mobile reader is upon us, thanks to iPads, Kindles, and smartphones. So why is it so hard to create mobile content? There's a shocking lack of tools to craft books, monographs, magazine articles, white papers, and other content for use on mobile devices for the ePub format deployed in e-book reader apps such as Apple's iBooks and Amazon.com's Kindle, much less for the kind of scalable presentation seen in the few good magazine and newspaper apps like those for the Economist, the New York Times, and the San Francisco Chronicle.
It's easy to distribute the two main formats (ePub and Kindle's Mobi): iOS devices let compatible apps open them from email attachments and Web links, and of course you can sync the files via iTunes or cloud storage services such a Box.net and Dropbox. As for Android, you can't open them in Google's native Books app or Amazon's Kindle app for Android; unlike their iOS counterparts, they're limited to store-delivered content. It's easy to distribute ePub and Mobi content to iPhone and iPad users.
[ Get the best apps for your mobile device: InfoWorld picks the best iPad office apps, the best iPad specialty business apps, the best iPhone office apps, the best iPhone specialty apps, the best Android office apps, and the best Android specialty apps. | Learn how to manage iPads, iPhones, Androids, BlackBerrys, and other mobile devices in InfoWorld's 20-page Mobile Management Deep Dive PDF special report. | Keep up on key mobile developments and insights via Twitter and with the Mobile Edge blog and Mobilize newsletter. ]
Yet the creation tools that are available for both business users and publishers to create such mobile-savvy documents are simply terrible.
The two publishing tools you'd think would be ePub-savvy -- Adobe InDesign and QuarkXPress -- are decidedly not, despite coming out with new versions this year. InDesign CS5.5's export creates messy code based on wild guesses as to content relationships, it ignores local formatting such as boldface and italics, and it doesn't embed the font information needed to display special symbols. QuarkXPress 9 has the same flaws as InDesign, plus more: It limits the mapping of text styles to just a handful of CSS equivalents and doesn't let you control output resolution of your document's images.
In both cases, these sclerotic behemoths generate ePub files that require a lot of manual massaging in a tool such as the Google-hosted, open source Sigil, which is the best ePub editor out there as far as I can tell -- despite the fact it's both awkward to use and does its own "what the hell?" transformations to your files. I can tell you from experience that you'll have to rework much of the underlying XHTML code manually, engaging in hours of effort that errant typos can quickly destroy.
Adobe and Quark seem intent on keeping it that way; both try to push users to their very expensive corporate publishing systems that act as content management tools for the Web, database publishing, and mobile, while letting ePub export remain primitive at best. Given that the client tools are so bad, it's hard to trust that investment would be rewarded.
On the business documents side, Microsoft Word has no ePub export. By contrast, Apple's Pages has ePub export, but the Mac-only software is stupid about text styles for both imported and exported text. You pretty much have to reapply all the styles in Pages for them to exist for the ePub export -- and that's important, as styles determine basics such as what goes in ePub files' autogenerated TOCs. Pages also litters your ePub file with span tags, a hugely inefficient markup approach that's also hard to edit. Styles are also essential to tweaking the CSS so that it can handle the ePub readers' varying support for different aspects of HTML -- it's a Wild West out there in terms of readers, not just creation tools.
Apple's iBooks, for example, requires image widths to be set via CSS styles, whereas most ePub readers handles the function in the img tag; you have to code both ways in the same document. And iBooks doesn't honor embedded fonts in documents; for example, if you want to use a monospaced font to indicate code, too bad -- it displays as one of iBooks' handful of built-in fonts.
The situation is a little better for the Amazon Kindle's proprietary Mobi format, but not much. The Mobi format is very limiting, moreso than the subset of HTML that is ePub; you can't, for example, wrap text or have hyperlinks to external sites (I suspect the function is based on Amazon.com's closed-world business model). Amazon.com does offer a plug-in for InDesign to directly generate reasonable-quality Mobi files, and there's always the Calibre open source app for converting ePubs to Mobi files, which also works well within the Mobi format's limitations -- once you've set the ePub files set, that is.