REVIEW: Adobe Digital Publishing Suite

Digital Publishing Suite’s Online Services

At this point in the DPS process, the work shifts from InDesign to the web applications that make up DPS online. The hub of it all is the Folio Producer, where folios are prepared for publication. As a web developer, I must say that Adobe has done a great job bringing clean, robust web applications into their portfolio these past few years. The Folio Producer has no bugs I can find and the user experience is very solid. One could say these web applications aren’t as robust as the desktop applications we’re used to from Adobe (the Folio Producer’s feature set is small compared to InDesign’s) but Folio Producer does have some metadata controls that aren’t anywhere else in the DPS and it’s where folios get published.

Designers and developers will probably spend more time with the Viewer Builder Service, which lets you build an viewer app of your own that carries your branding and can support single publications, multiple publications, subscriptions and/ or print-and-digital subscriptions. The digital publishing process becomes a lot more labor-intensive when the Viewer Builder is involved, because it really is app development and you have to obtain all the necessary developer credentials. For example, Apple requires distribution and developer certification and provisioning files for both, as well as icons and splash screens for your app. These requirements help Apple maintain high quality in their app ecosystem but novices can easily get mired in the details.

Once you get your developer credentials in order, the Viewer Builder app where you build your custom app is actually fairly simple. Most of the Viewer Builder involves adding custom icons and settings. Enterprise Edition users can do more with the navigation icons. I’m actually disappointed you can’t do more with the colors and the user interface, or add your own (perhaps a set of links in a flyout menu?). The Viewer Builder has the most room to grow out of all the DPS services.

Professional and Enterprise users (see below) have access to the crown jewel of the DPS product: the Analytics Service, which has its foundation in Omniture, the analytics company Adobe acquired a couple years ago. Omniture’s products are the basis of Adobe’s web analytics portfolio and its technology now powers the analytics behind the DPS. As with the Folio Builder, the Analytics web application in the DPS is clean and easy to use. I’m very impressed how well the charts and graphs are drawn up in the Analytics application—I’ve seen other online platforms show weak charts in comparison.

The Analytics Service keeps track of a healthy amount of data but actually not as much as I expected. Here’s a list of data you can track:

  • Installations of your custom content viewer app,
  • Launches of your viewer app,
  • Edition downloads and download errors or cancellations
  • Downloads broken down by day
  • Purchase data
  • Most-viewed articles, ads and videos
  • Most-viewed content by overlay type (Image Sequence, Panorama, Audio & Video, etc.)

I think there’s more valuable data to be gathered by the Analytics Service. How do people read editions—do they read cover to cover, or do they browse various articles? And in what order? I also wonder if individual users can be tracked to, for example, determine if a particular issue was purchased more by new users or by longtime users. I think this tracking of users’ reading and buying habits will be the next vital addition to the DPS’s analytics. The Analytics app itself is already strong and easy to use, but I think some more metrics will make businesses and publishers really salivate.

The Output

The output of the DPS has come under scrutiny before for producing enormous files— here is a good article by Peter Kafka about Condé Nast’s publications being quite large, such as an issue of the New Yorker being 173 megabytes. This was written in September 2010 but Adobe has not done a lot to cut down the amount of data being output. The main problem comes in when publishers use a lot of multimedia—which, unfortunately, is a major reason for building digital publications in the first place. Overlays created by the Overlay Creator add a lot of images to a publication, which are many times larger than text.

But I am starting to suspect large file sizes are unavoidable. Recently Apple released a major initiative for digital textbooks and the iBooks Author product for producing textbooks for the iPad. Cult of Mac found that most of the textbooks available through iBooks are between 1,000 and 3,000 megabytes (or 1–3 gigabytes), many times larger than the New Yorker example. One could argue a textbook can’t be compared to a magazine but I disagree—a year’s worth of New Yorker pages would easily be hundreds of pages.

As with personal computers in the 1990s and the 2000s, I believe file sizes will keep going up and mobile devices and tablets will have to get more storage capacity. The cloud will also alleviate the problem, serving as storage for back issues. Adobe and Apple both need to cut down on code and media as much as possible, but I think the future will show you can only cut so much.