The rise of the ebook has really shaken up publishing over the last few years. Actually, that needs qualification – it has really shaken up fiction publishing. Other sectors have so far been less stirred. Can EPUB, HTML5 and XML help, or are they a burden?
Smartphone ownership and content consumption have risen faster than anyone expected. As ever, convenience trumps most other factors, and it turns out that people are willing to read even long-form content on their phones. Perhaps surprisingly, it looks as if making your content “bite sized” for phones isn’t really the problem – it’s simply about making it available in a readable format.
If we think about content discovery, the picture is even more extreme. 80% of Twitter’s traffic is on mobile, so there’s not much point tweeting a link to something that won’t work on a phone.
This is obviously a huge opportunity for publishers. But it’s one that is challenging to meet while still satisfying the demands of the existing business, and most likely without any additional staff.
A big part of the problem is that the tools in common use, typically Adobe® InDesign®, were never intended for this scenario. Their base assumption is a fixed page size.
As somebody who works at Adobe once told me, “InDesign is a paint program”.
In an ideal world, you’d build a “create once, publish everywhere” workflow that let you prepare content just once with confidence that you could deliver it onto any device.
Unfortunately, EPUB has not proved up to the task of delivering content that is richer than plain text.
Fixed-layout EPUB is little more than ersatz PDF. In theory it can be more semantic and give you some extra features. But none of the conversion tools that generate it from PDFs will give you good-quality HTML, at least not without human intervention. All you get is a page replica that will not scale down onto a small screen any better than a PDF would.
It’s a bit hard to see the point of it.
Print replicas, whether PDF or fixed-layout EPUB, cannot deliver into a mobile world without very serious workflow cost implications. You would need to prepare a separate version for (each different size of) small screens. Then what happens if wearables like Google Glass take off, and it turns out you also have to deliver onto an even smaller screen…?
One thing that EPUB really has got right is that it’s built around HTML5, the nearest thing we have to a truly cross-platform, future-proof-ish content standard.
But there are other ways of delivering HTML5 that do not have the problems of EPUB – namely websites and hybrid apps. The hybrid app model is becoming increasingly popular, both because it is more easily monetisable through the app stores, and because “people like apps”.
There are a wide range of tools and workflows available for producing HTML5. Which to choose?
XML-based workflows can look like a panacea: convert your content to XML and you can run it through templates for every device or platform you’re targeting. For publishers (mostly academic) who have already invested heavily in this approach, it can work well enough.
But others will find big hidden costs. Step 1 here is “first catch your rabbit”, or rather “first, structure your content”. That means significant extra effort in tagging it up, or even rekeying it into forms in some new system.
But content doesn’t particularly want to be structured, so you’ll discover extra costs grappling with edge cases and content that doesn’t fit your original schema.
Worse, these kinds of workflow front-load the design step. Design is all baked into templates before the content arrives. That places serious blockers on creativity and quality of output. Suddenly, developers are the gatekeepers of design. But in a rising tide of content, it’s more important than ever for publishers to ensure the quality of what they produce.
HTML5, it’s worth remembering, is a standard that accommodates cross-device presentation (through CSS) as well as semantic markup. It makes no sense to throw that away.
There’s no easy answer here, and the best route to achieving a practical digital workflow will depend on who your audience is and what systems and workflow you already have in place. But here are some criteria to consider as you look for a solution.