Easy to design and a clear path to money–that is what publishers hoped to find when Apple first released the Apple iPad and the term “digital publishing” came to mean publishing for mobile devices. The truth is more complicated.
Adobe Digital Publishing Suite (DPS) Single Edition is included with the Adobe Creative Cloud offering. The desktop-based Design Premium Creative Suite CS6 comes with Folio publishing capabilities and the DPS App Builder application. The Single Edition allows for single issue apps on an Apple iPad. Anything beyond that will require a more expensive, more-of-everything account.
Anyone who has InDesign CS6 or CS5.5 on his or her system is able to immediately start designing and previewing folio publications, but you need to buy a Single Edition license before outputting to an app is possible. CS5 users must first download software from the Adobe site.
For single issue apps — let’s say an eBook with illustrations — the workflow is pretty simple: Design the layout, add the interactivity and output to folio. Then go to Adobe’s DPS online dashboard. That’s the browser-based interface where you manage your Folios, the term for the publication file format InDesign creates. Ultimately, the system will convert it into a tablet app.
If you want to create other effects than what you’ll find in the already quite complete set that’s included with InDesign CS6, just buy a widgets set like the SmartDPS set from WoodWing Software. Anything else in terms of more complex animation or HTML-based effects requires a trip to Adobe Edge Animate or Adobe Dreamweaver. For layout designers who know InDesign and little else, this complicates things, but there’s more complexity hidden in DPS itself as well.
For example, why do you need the intermediate step of the folio file? How do you add something as simple as a search box? How do you make that search box go out on the web and return “See Also” content, instead of just the stuff that’s already in the app anyway? With digital publishing in general, but Adobe DPS in particular, things quickly get confusing. Take the WoodWing widgets, for example. They’re HTML5, which makes you wonder whether the .folio format InDesign spits out is HTML5 too.
The answer is: No, it isn’t.
I dissected a locally-saved Folio and found it is nothing more than a zipped collection of folders and files. Some very lightweight hacking will decompress that.
The core of this folder is the article subfolder that contains an XML file. Then there’s a “mimetype” file, a property list, some effects resources (that is, overlays) and the content itself is in a … PDF.
That’s right.
The digital app you’re about to create is really nothing more but a glorified PDF. It looks easy and simple, but it isn’t.
For starters, PDF is heavy. Dump some effects in it and it becomes larger and heavier. Your tablet is going to need some serious muscle to make it all look smooth. PDF also is limited in what you can do with it. It was conceived as a print format, but Adobe uses it as an intermediary for an interactive, digital content container.
One of the limitations with DPS, for example, is that only text that you render as static is searchable. Text contained in a scrollable frame, or to which an effect is applied, is rendered as PNG, JPEG or vector image and then embedded in the PDF.
Another strange thing is that images containing the effects (to be rendered in the app) that sit in the Folio folder all contain references to Flash. An iPad doesn’t support Flash, so why the reference to it?
But there’s more. Adobe can render a HTML preview of the .folio file that works across web browsers so design team members can see the publication — not the app — and share it via social media even.
So why doesn’t Adobe just replace the PDF part by HTML and render it out as HTML5 in the finalized app?
That’s perfectly doable, as the competition has shown. One advantage of the HTML5 approach is that text, no matter how you render it, becomes fully searchable.
I’m sure we would all agree the ability to freely search an article or story is one of the most compelling features of any digital rendition of textual content, be it browser-based or an app. If a story can’t be searched for keywords or sentences, it might just as well be an ad.
Adobe’s answer is that nothing stops you from using HTML for part or even the whole publication. That’s an overly simplistic representation of things. If you want to render that HTML content with an effect, you’ll have to hardcode the link between the rendered and actual content. This makes your app more bloated yet again, which in turn takes more time and effort you don’t want to waste.
On the other hand, if you replace good old PDFs with HTML5, text is natively searchable.
I asked Adobe’s rep for comment. The rep just said Adobe doesn’t plan HTML5 apps.
But I believe text search is something that should be on the roadmap. The rep disagreed. According to him, The New Yorker uses HTML extensively and, with it, gets search capabilities, too. How useful that search feature is will only be revealed to users of that app.
It needs to not only search for what’s in the app but also on the web to find related content.
Digital publishing and, especially, DPS, is a complicated matter. There’s a lot for publishers to customize — that explains why the system appeals to publishers with bags of money. And, according to the rep I interviewed, even those publishers don’t design for multiple tablet orientations.
