Magazine publishers—especially larger ones with multiple syndication and distribution channels—have struggled for years with finding better ways to manage and automate the use of their valuable intellectual property. Content Management Systems (CMS) and Digital Asset Management (DAM) systems have been tried as tools for more efficient production—from finding the right asset, to using it (legally) in a specific publication, to repurposing it in an ever-increasing number of print and digital channels. The results have been mixed, and often disappointing.
An alternative that seems to be getting traction is that of making individual assets (rather than entire articles) “smarter” and thereby easier to use in a multi-channel production environment. A CMS or DAM environment based on this premise would in theory let production professionals easily find and use relevant content—not only based on the article’s specifics, but also on the asset’s relevance to a particular platform. For example, a print designer would see only text and static images, while a tablet or other mobile designer would see related but mobile-specific media like video or animations—or lower-resolution versions of static images. Each would have access only to assets for which sufficient rights were secured.
The Mobile Push
Print and Web production workflows have each evolved their own CMS and DAM approaches—typically separate ones—for facilitating high-volume production. However, the recent move towards mobile publishing [see “Defining Mobile Opportunities and Strategies” starting on page 40], for both smartphones and tablets, has made the need for a better CMS/DAM infrastructure acute. With a rapidly-expanding number of mobile platforms and devices, a robust content repository is an essential cost-saving factor.
Sean Keefe, director of publishing technology at Hearst, points out that publishers’ CMS and DAM infrastructures are in fact evolving to meet this new challenge. Hearst’s own systems were originally developed to store published content, to dynamically feed Hearst magazine Web sites, and to serve the needs of third-party aggregators. Like many publishers, Hearst uses IDEAlliance’s Publishing Requirements for Industry Standard Metadata, or PRISM.
One solution to the problem of properly structured articles has been to use Adobe InCopy templates, with correct tagging already in place.
“Magazine publishers have a wide range of needs, from structured, news-oriented content to more design-intensive content,” Keefe says. “Content management and DAM will evolve differently for each type of publication, based on the kind of content being created.”
At Time Inc., a similar use of CMS platforms for Web (Vignette and others) and print (WoodWing) have created significant cost savings for mass production of high quality content, according to senior vice president Mitch Klaif. “Mobile media has been the catalyst for our adaptation to multi-channel publishing,” he says. “Web CMS’s are increasingly becoming a presentation agnostic data source of content, rather than just a Web page production platform.” Time is currently evaluating CMS platforms that offer “create once, publish many” capabilities, but Klaif notes that it is too early to know if these can meet Time’s multi-channel needs.
“In print and digital magazines, the challenge is to find a way to structure the content as it’s being created, without interfering with that content creation process,” he says. “Most magazine content can’t be structured easily without compromising the quality of the content.” Klaif goes on to note that pre-tagged templates are part of a possible remedy, although limiting how much designers can stray from those templates can have unintended effects on the quality of the product.
Seeing Through the PRISM
A significant new development is this year’s release of the PRISM Source Vocabulary (PSV), which includes new metadata elements that support workflows for mobile, Web, tablet, and print. The new PRISM specification uses HTML5 for content encoding, making it much more interoperable than prior versions.
PSV 1.0 begins to address the dilemma faced by less-structured, more design-intensive magazine content. It does so by shifting from structured layout to semantics, tagging each content element with required metadata (type and unique ID) as well as optional elements (description, relations, components, usage rights, and indications of where it was used). PSV is not an authoring tool, or a content display format, so there is clearly a lot of work to be done in the practical tools arena. The tools needed to make PSV practical are made by several partners in the nextPub initiative, the IDEAlliance working group that authored the specification. These include Adobe, WoodWing, HipZone, MediaBeacon, MarkLogic, and many others.
Not everyone is convinced. Tony Byrne, a senior analyst at the Real Story Group (formerly CMS Watch), is skeptical of the single-source data approach envisioned in PRISM. “Rich markup and metadata alone doesn’t do the whole job,” he says. “For publishing, you’re going to need a hybrid model, especially when it comes to things like rights and distribution rules. It’s important to track enterprise information on one level—the master database—while still leaving decision-making possible at the user level, a ‘federated’ model, if you will. Rather than require a single, fixed-rules data repository, users should be able to make decisions about content use in a particular edition, or on a particular platform. The original ‘parent’ data would be aware of that decision, but would not control the decision of the ‘child’ application.”
Byrne notes that PSV may provide a starting point for a shared CMS/DAM vocabulary, but that no one has yet succeeded in creating the “federated” model.