The horrible state of mobile publishing

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.

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.

For periodical content, QuarkXPress 9.1 released in early September was meant to usher in the age of iPad content distribution. It promised to let you create a container app for your content that readers could then use to get your latest issue, book, white paper, journal, or whatever for free, for a subscription fee, or for a per-issue cost as you determined. It was supposed to use the “liquid layout” approach for its content, so readers could increase the text size and have the layout reflow automatically — as the Economist, New York Times, and San Francisco Chronicle mobile apps all do. Contrast that with most publications, which create a fixed presentation very much in the style of a PDF that either cannot be resized or that when resized requires horizontal scrolling to read the text in the enlarged view. That isn’t the way mobile’s heterogeneity of screen sizes and user adaptability are supposed to work.

What Quark actually shipped didn’t include that long-promised reflow capability, so all you get are glorified PDFs in a container managed through the App Store — and maybe not even that. I tried for a good week to create an app container using Quark’s app, its website, and the iOS developers website; all three are involved in the complex process. Even with Quark’s human assistance, I never managed to create an app. The instructions changed each time, and ultimately they stopped trying to help. I strongly suspect it’s a work in progress. What does work is its preview app, so I could verify that the ultimate result is a glorified PDF viewer.

QuarkXPress is the only mainstream tool available to consider — Adobe is missing in action on the mobile content front outside of mobile-optimized HTML in its CMS offering.

When you consider Amazon.com’s magazine capability in the forthcoming Kindle Fire tablet and Apple’s Newsstand app in iOS 5, it appears as if only major publishers with gobs to spend on specialty publishing systems can participate in the mobile magazine business.

I know from my Web experience that tools are slow to catch up with the technologies they serve, at least when it comes to creating content. Even today, a good decade after the rise of the Web, most content producers moan about their content management systems — none has the sophistication or user orientation of a desktop publishing tool. Maybe I’m naive to think mobile content creation tools should actually work — and work well — before 2020.

Technology is moving faster than ever, and the highly manual, error-prone creation processes for mobile content today aren’t scalable or sustainable. Adobe, Apple, and Quark don’t seem to get it, and Microsoft doesn’t seem to care. It might be time for something disruptive — like the first version of QuarkXPress, the early versions of Word for Windows, or the original Mac’s inherent font-savviness were in their time. I’ve seen a bunch of startups talk about addressing this need, but I haven’t seen anything substantive (most are appified HTML viewers, and there are a few services like Zinio that take the unsatisfying glorified-PDF approach) — I hope that changes soon.

This article, “The horrible state of mobile publishing,” was originally published at InfoWorld.com. Read more of Galen Gruman’s Mobile Edge blog and follow the latest developments in mobile technology at InfoWorld.com. Follow Galen’s mobile musings on Twitter at MobileGalen. For the latest business technology news, follow InfoWorld.com on Twitter.