hold, we are seeing a steady migration
toward workflows with digital content taking
precedence over print. And with the advent
of digital-first authoring environments
(Inkling, Habitat, Metrodigi’s Chaucer),
the CMS becomes inevitable.
A CMS is not going to be an out-of-the-box solution. A publisher’s particular business rules and workflow-management
needs will require months of development.
In order to function as intended, the CMS
will require consistent tagging across all
content. A CMS is not inherently user-friendly. If everyday users are going to
easily retrieve and validate downloads from
a CMS, they will either need to be familiar
with query language, or the system is going
to need an interpretive layer to accommodate them in a more user-friendly mode.
Going back to the comparison of the
PDR to a Honda, the CMS is something of
a tank. Systems are incredibly dense and
powerful. The dynamic interactive repurposing of content at a granular level is the
metaphorical equivalent of going into
battle—it requires a tank. It is complicated,
expensive, and time-consuming to build,
but it is the right vehicle for the job. It is
not, however, the right vehicle for driving
from New York to Boston under typical
A PDR is easily ported to a CMS when
the time comes. The two system fit hand
in glove. For most publishers’ immediate
needs, the answer may be to start with a
PDR and let the market dictate when a
CMS has become necessary.
Where Are We, and Where Do
We Go from Here
Publishers are facing a number of poten-
tial pitfalls going forward. Some of these
are related to an uncertain market and
delivery system, such as a Web server.
A PDR is often a simple relational database, providing sophisticated search and
retrieval while remaining user-friendly. It
can be internally developed or adapted
from a third-party system to the publisher’s
particular needs. The economic advantage here is that such a system is relatively inexpensive and quick to employ.
The PDR is an assembly of content. It is
not possible to semantically search
across an entire library of digital content
in a PDR. One can, however, prepare content at a very granular level for future use.
With digital-object identifiers (DOIs) stored
as metadata, a publisher can tag individual
chapters, or even objects within those
chapters, for a time when they might be
Perhaps the most important question
for publishers to ask is whether a PDR
meets their most immediate business
needs. Often, those business needs are
tied to storing, tracking, accessing, and
retrieving finished goods and content
quickly and reliably. Such modest needs
could be metaphorically thought of as
what mode of transportation is needed to
drive somewhere. If the publisher is going
from New York to Boston and is not planning to go to battle along the way, then
perhaps a Honda is the best bet. If it
serves the publisher’s most urgent
needs, then a PDR may be the cheapest,
quickest means to an end.
On the other hand, while a CMS can
replicate the functions of a PDR, its power
lies in the structured assembly of content,
allowing the publisher to perform a
semantic search across an entire library
and dynamically retrieve and repurpose
discrete elements. It is key to interactivity
between user and content.
It is probably true that most large
publishers are going to need a CMS
eventually. What is less recognized is that
publishers rarely need such a powerful
tool when managing content at the book,
article, or even chapter level. The market
is tempting us with possibilities, but there
are presently not that many real-life com-
mercial demands requiring CMS function-
ality. The PDR fits most present-day
commercial needs. However, as Web-
based content-delivery platforms take
evolving technology, but some are of our
own making. It is a challenge to reconcile
our own business strategies with quickly
changing and complicated technologies.
And there is always the chance of making
The market for publishers appears to
be in a world shifting between print and
electronic. While the fortunes of print con-
tinue to decline, the promise of electronic-
product revenue has yet to be fully real-
ized. There is confidence that the digitiza-
tion of content is going to eventually
recoup lost print revenues, but there is
not yet any clear vision of what the market
is going to demand going forward.
The best strategy is to be prepared for
any eventuality. That means ensuring that
archival content is consistent, well struc-
tured, and easily retrievable, and that new
titles are properly vetted for quality and
consistency before being archived. It also
means not letting content structure be
defined by full-service suppliers. A system
for managing content is essential; what
form that takes is dependent on each pub-
lisher’s business needs.
Here in 2016 there is a good deal more
certainty about the digital market for con-
tent than there was a decade ago. Still, a
number of markets are far from mature.
What is certain is that the bold executive
decision isn’t about choosing one format
over another. It’s not about predicting
what markets will do. It’s about being
prepared to execute and deliver content
to whatever market presents itself.
To read the full white paper from which
this article is taken, go to publishers-
Sponsored by CodeMantra
THE TECHNOLOGY-PUBLISHING CONNECTION
This article is the first in a print and webinar series presented by CodeMantra on how
publishers can best use technology to expand their businesses. The series will feature four print articles and four free webinars.
The first free webinar, called Technology Simplified, is set for October 5 at 1 p.m.
EDT. The panel includes Michael McGinniss, head of digital transformation at
Accenture; Samantha Cohen, v-p, design and digital content development at Simon &
Schuster; and Randi Park, publishing officer/publishing and knowledge at World
The second webinar, the Importance of Metadata, will take place October 12. Other
installments set for later this year are Working Together and Book Apps vs. E-books.
Rick Beardsley is the former v-p of
production at Taylor & Francis.