Planning for Multiplatform Publishing
Publishers plan their content production development strategy with care.
With so much at stake, and so much potential labor cost involved in maintaining multiple channels, many publishers are being cautious in planning their long-term content strategies. (Some publishers we spoke to interpret the phrase “long-term” to mean about two years.) To many publishers, tablet and smartphone output are both facets of their overall mobile strategy, especially as smaller tablets and phone-tablet hybrids proliferate. To others, tablets and phones are entirely separate.
With so many different devices and screens in subscribers’ hands, the days of simply re-purposing print content workflows for a single device—the 1024 x 768 pixel iPad—appear to be over.
Not So Fast…
Before delving into the “create once, output for multiple channels” approach, it should be noted that many publishers—particularly smaller ones—are still perfectly content to re-purpose their print content PDFs as enhanced digital replicas. There are many service providers that, for a modest fee, will convert PDFs, add interactive elements—or provide Web tools for clients to do so—and manage delivery to the major tablet platforms. One developer asserted that many publishers are choosing to support only three major tablet platforms (Apple iPad, Samsung Galaxy and Amazon Kindle Fire)—at least for now. While not all tablet screens have aspect ratios comparable to that of printed editions, many of them come close enough to keep the enhanced facsimile alive for the near term.
Native apps are not the only “containers” for enhanced tablet editions. Publishing service providers like Nxtbook Media, BlueToad and Uberflip (formerly Mygazines) have introduced HTML5-based Web apps that solve many of the OS- and device-related problems of native apps—making magazine content more practical on a wider range of tablets and smartphones.
Given the labor and subscription costs of hosted publishing management systems, there is clearly a tier of publishers that will choose this type of solution for enhanced facsimiles for the foreseeable future.
Of course, not all publishers are satisfied with the gradual, evolutionary approach. Anthony Astarita, senior vice president at Rodale, described the publisher’s technology development aspirations when it came to multiplatform publishing. The self-described “health and wellness content company” is about more than its consumer magazines—with extensive book publishing, social media and e-commerce ventures and over 27 million active customers in its database. So it came as no surprise when Astarita highlighted the company’s technology investments, including big data analysis, cloud services, content delivery networks, DAM, Digital Rights Management (DRM) and security. “The key drivers in content [are] knowing what you have and being able to get it,” he says. “Secondary to that is introducing intelligent systems that can begin to learn the data and the consumer, always trying to make the experience for them more relevant.”
Protecting content is also high on Astarita’s priority list. “Integrating DRM and licensing metadata into the content [allows Rodale to] more aggressively go after syndication opportunities to drive new revenue streams.”
Although Rodale is immersed in sophisticated data management, Astarita emphasized that their publications’ multiplatform content delivery was still based on a “design first” and “product-centric” approach, necessitating long-term investment in people with user experience and cross channel expertise. Within the next few years, he predicted that Rodale’s mobile publications would be far less constricted by operating systems like iOS, thanks to trends in responsive design and abstraction frameworks like PhoneGap and jQuery.
Business titles are finding that managed content is especially valuable when combined with the right publishing automation tools.
Paul Winston, associate publisher of Business Insurance, points out that tablet app development was “the best platform for long-form news and analysis supported by data, sidebars [and] graphics,” as well as display ads originally designed for print. “We are attracted to content technologies that allow us to leverage production and distribution across multiple platforms or channels, rather than requiring our team to reinvent the wheel for every platform we use.” The company adopted Quark’s AppStudio environment, creating native apps for iOS and Android and (more recently) an HTML5-based Web app. AppStudio’s handling of the company’s managed XML content allowed them to easily generate digital back issues, in addition to the more interactive content of the current tablet issues.
Wolters Kluwer Health embraced Adobe’s Digital Publishing Suite (DPS) as a natural adjunct to their existing CMS and editorial systems to develop over 150 journal apps. Marketing VP Sami Hero notes that the resulting content offered “new ways to engage our editors, authors, readers and advertisers. For example, for many medical specialties, such as surgery, video supports enhanced education and learning for practitioners.”
While many publishers are moving forward with integrating their own systems with the likes of Adobe DPS, a few have raised concerns about the proprietary nature of the .folio format used by DPS and its partners, including WoodWing. IDEAlliance’s OpenEFT specification is an attempt to address this issue. Vice president of emerging technologies Dianne Kennedy says that previous XML specifications were well suited to highly structured publications, but less so for design-driven ones. If adopted, OpenEFT would help bridge that gap, Kennedy maintains, by establishing uniform, platform-independent definitions for components such as video. It would begin to establish a common ground for publishing in a multi-screen environment by working with aspect ratios (rather than absolute screen sizes) as well as scaling percentages and relative element positioning. The first iteration of OpenEFT is scheduled for publication on September 29, 2013.
Kennedy says that OpenEFT and similar specifications were aimed at responsive design approaches—perhaps tied to emerging “liquid layout” capabilities on the design side, and that HTML5-based Web apps were the likely direction for a standards-based approach to publishing.