Home Archives Profile Subscribe

The digital content scalability problem

Screen Shot 2018-05-20 at 3.04.46 PMWhy are ebooks still stuck in the print-under-glass model? Why haven't we seen anything new and exciting in the digital book transformation process?

Those are questions I've been asking myself a lot lately. Ebooks are convenient in that you can carry an entire library on a phone or tablet. They're also more readily available for browsing or purchase, right from the comfort of home. But the reading experience features nothing more than a digital version of the print edition.

I've spent a lot of time evaluating content transformation platforms over the past several years in the hopes that I'll discover the path forward from today's world of dumb books on smart devices. I'm disappointed to say we're at roughly the same stage as we were at more than 10 years ago when the Kindle first hit the scene.

The problem? Scalability.

There are countless books which could be greatly enriched by leveraging technology. Everything from the simple insertion of video to the addition of more interactive elements would turn a static experience into a much more memorable (and probably more effective) experience. These enrichment platforms are becoming easier to use, enabling drag-and-drop functionality so you don't have to be a programmer to create a rich user experience. However, the cost of creating these next-gen products is typically more than what the publisher invested in the creation of the original print product.

Think about that for a minute. As a publisher, you have a pretty good sense of the ROI for your next new title. Most of the variables involved operate within a fairly tight range (e.g., author advance, editing expense, manufacturing cost, sell-in level, etc.) Even the total sales, and therefore resulting revenue, are fairly predictable, within a given range. All this predictability provides the publisher with a P&L model without a lot of surprises.

Now think about asking a publisher to spend two or three times that initial product investment to create an enriched version of the same title. The product development expenses are higher, and may even result in cost overruns due to the newness of the approach. More importantly, the resulting revenue projection is a total shot in the dark. Until the publisher has created enough of these new products, they have no idea what sort of sales range to project.

Scalability should lead to better efficiencies. We saw this with ebooks; an ebook can be created today at a fraction of what publishers used to pay for the service 5-10 years ago. The same thing needs to happen with enriched content. Vendors need to have a path to a model where the transformation cost is less than half the original print/ebook product cost. If they're unable to get there, they might as well abandon ship and get into a different business.

Agile publishing: Creating better books through transparency

MCTrade book publishing is not a complicated process. Publishers acquire the rights to publish new titles primarily through relationships with agents. Once the agreement has been signed, the process from manuscript to shipping is fairly predictable and more or less linear:

Acquisition => Manuscript => Editing => Prepress => Production => Marketing => Sales

Each step of this process can be clearly identified by the associated teams who work on each step (e.g., Editorial, Design, Marketing and Sales teams). This siloed approach to publishing has, for the most part, worked for more than a century, helping publishers effectively deliver a finished book to the marketplace within a reasonably well-projected window of time based on their capacities.

The problem with this approach is that while it focuses on the activity of bringing a group of titles to market, it neglects how publishers might improve their products through a more collaborative and transparent approach.

This is where I believe agile thinking can help.

What is agile?

Beyond the standard definition, in the software development space agile is known as a set of principles related to how projects and teams operate in producing “potentially shippable increments” to market.

You may be thinking “How could publishers benefit from agile, when their goal is usually to deliver a single, finished product to the marketplace instead of software that is released in continuous versions over time?” It’s a good question, so let’s consider how three specific agile practices within the Scrum framework could better help publishers to deliver higher quality new titles to market with each release cycle, known as a span, resulting in better per-title performance and quality as well as more collaborative cross-departmental teams.

Scrum1

One method for managing development throughput in software is know as Scrum. The term Scrum is taken from the game of Rugby (scrummage) when play is resumed after a stoppage. In technology, Scrum is best thought of as a framework for defining and prioritizing a set of tasks for small specialized teams to work on in intensive work sessions known as “sprints.” Sprints typically last two to four weeks in duration and are highly focused on accomplishing a prioritized set of tasks (the backlog) decided upon by the Scrum team at the Product Owner’s direction at the beginning of the sprint during a dedicated planning session.

It’s in this initial session when the team decides, based on their technical understanding of the requirements for a set of tasks, an estimation of how much time will be necessary to complete a particular sprint. If the estimation exceeds more than a few weeks, then the work may need to span more than one sprint. Completion of a sprint must always result in a “potentially shippable increment” of working software. The following three practices are a part of all successful Scrum teams’ workflows and if implemented within publishing teams, I believe they will also result in a similar outcome: a high quality “shippable” product and improved team dynamics based on a high level of transparency and communication.

Estimating

Estimation is admittedly a guessing game, hence the name. However, a good scrum master (in the case of publishing this would be the Managing Editor) will rely upon daily Scrums and retrospectives (more on those in a minute) and reporting to help better estimate toward the future. One such report, known as the burn down chart, tracks the estimated amount of time needed to complete the work at the beginning of the sprint on the x-axis and then projects a downward line as work is completed throughout the sprint, with the line ideally resolving at zero on the y-axis at the end of the sprint.

This chart is the tool by which a team’s ability to estimate is measured. With this information gathered and analyzed over time a good Product Owner (think: publisher) will be able to better forecast the necessary investments to complete versions, or titles, in order to meet the goals for the overall business.

In my experience working on and with publishing teams, the process of estimation is, for the most part, one that relies strictly on financial forecasting at the acquisition phase instead of incremental evaluation and adaptation in the way that Scrum does. At the beginning of a book’s life cycle the “Pub Board” as it is affectionately termed, performs a financial estimation plugging in numbers such as cost of goods, marketing, advance and ongoing royalty percentages as well as other line items along with a “guesstimate” of first year sales and a unit projection for a set number of years beyond that know only as “lifetime” or “balance.”

The cost side of this process is typically estimated based on actual historical figures as publishers typically have a good handle on printing, obsolescence, freight and other expenses. However, the guessing game around how many units a title will sell is always  just that. And in that way, publishers typically don’t employ the same decision making process as software teams when making decisions about future releases. Sure, many publishers employ the use of report cards that track projected vs. actual numbers, however this data seldom makes its way back to the acquisitions team in future rounds of projections. Instead, teams typically look on these numbers strictly as an indicator of past performance.

Overall, the evaluation of a span’s performance is primarily sales oriented and after the fact. Seldom do publishers take the time to consider the effect the publishing process, including the teams involved, have on a book’s ultimate performance.

How it’s done

By employing agile estimations in publishing, the Publisher and Managing Editor should gather all teams together at the beginning of a cycle/span to go through each release in detail, outlining the requirements. This meeting will take a number of hours to complete, planning at least an hour for every three titles in a span. During this meeting, the Publisher will detail the overall goal for each title, including its hook, target audience and projected sales volume. The managing editor will then go through the logistics and technical aspects of the book: timeframes, trim size, binding, etc. This process will give each specialized team an opportunity to ask any questions relative to their work as well as giving everyone an overall understanding of the role they play in the books success or failure.

Finally, all teams must agree to what success looks like for a finished span. This must be stated up front in order that the process and products can be evaluated at the end in order maintain continuous improvement.

By investing this time up front, publishers will see teams that are more personally invested in the overall success of a span and also take in qualitative feedback from team members that will help to better inform the process, including which books they acquire, in the future.

Daily scrums/standups

Publishing teams are notoriously siloed. This isolationist mentality has, quite frankly, gotten a bad rap. I, for one, am a firm believer in silos. As you can tell from the agile definition above, specialized teams are a prerequisite for agile methods to work, and in that way publishing closely mirrors software development. The problem most people often have with silos in publishing organizations is the all too familiar lack of communication that exists between teams when a project is deep inside of another team’s process. This is where the idea for “standups” comes in.

In agile organizations, teams working in the Scrum framework meet daily for fifteen minutes to discuss what each member of the team is committing to for that day. In publishing, those who would be mandatory at this meeting would be all team members responsible for a title or group of titles and it would be up to the managing editor to facilitate these meetings as a servant leader. This meeting is not a check-in to make sure folks are doing their jobs. Instead this meeting consists of three questions:

  1. What did you do yesterday to help us meet the goal for this span?
  2. What will you do today to help us meet the goal for this span?
  3. What impediments are standing in your way from helping to meet the goal for this span?

This process serves to clearly communicate how much work has been done and how much work remains. It also helps everyone to clearly understand any impediments that are stalling progress, which will have impacts further down the pipeline. It is then the managing editor’s job to work on removing the blockers so that work can continue.

This practice of daily standup meetings will further enhance communication within silos as well as bring transparency to a book’s development and help to alleviate any frustration before it begins for those further down the line.

Reviews and retrospectives

A sprint review is conducted at the end of a sprint and it involves not only the Scrum team (in this case the Publisher, Managing Editor and teams responsible for doing the work) but also any other stakeholders such as Marketing, Sales and other Executives who are invested in that span’s goals and performance.

A retrospective gives the Scrum team involved an opportunity to unpack what happened during the previous release cycle or sprint. In publishing, this is a process that should take place for the entire publishing team responsible for the work involved in producing a span’s titles. The purpose for a retrospective is to understand not only what happened, but how can we learn from it and make improvements going forward. This includes not only evaluating the products that were created, but also the processes used.

As in all things agile, this meeting is democratic and the team as a whole decides together how the meetings should be conducted. Of course, it is of paramount importance that trust be fostered in these meetings, so this is an opportunity for everyone to be reminded by the Managing Editor that we were all rowing toward the same finish line and everyone did the best job that they could. This should be laid out up front, which will ensure that no one casts aspersions at any other team member and everyone stays focused on the objective, which is to learn and improve both product and process.

Wash, rinse, repeat

Once you’ve implemented these agile methods into your publishing operation and gone through a complete cycle you will be amazed at the amount of communication that goes on. Of course, in publishing if there is one thing we bemoan it is the number of random meetings we’re required to attend on a daily basis. By implementing agile methodologies, namely Scrum tactics into your systems, the need for ad hoc meetings should diminish as the communication lines will be far more open and frequent through a systematic approach.

Through repeated use of title span planning meetings, daily standup reviews and retrospectives, your entire publishing team will be in-tune to the goals and performance of not only the finished products but the process itself. This discipline will, by its very nature force you to see where improvements need to be made and with a savvy Managing Editor and Publisher duo you should begin to see continuous improvements in your team and your products’ performance.

BONUS

One final tactical tip for you. To aid in the daily interoffice communication, I would recommend you consider eliminating email and move to some type of enterprise IM tool such as Slack or Hipchat. These tools will allow you to group interoffice discussions into themed conversations, providing needed visibility to other team members where email does not. There is still the necessary direct messaging built in to provide for private conversations, as well as the ability (in Slack at least) to quickly call someone or start a conference call in a channel (the technical name for a themed conversation). This tool has become critical in the teams I lead and I believe it could be a huge help to your team as well.

1 DISCLAIMER: It’s important to state right up front that these ideas are only pieces of the Scrum puzzle. True Scrum adheres to a whole host of rules and principles that when not executed entirely results in something less than Scrum. Because publishing houses typically work on spans over a period of a few months (spans), true Scrum is not an option. To that end, the following practices, while derived from the official Scrum GuideTM, do not comprise all of Scrum. For more information on all things Scrum, jump over to scrum.org.

This article was written by Michael Covington. With a unique background combining more than 10 years in bookselling, 10 years in publishing and presently serving as a product manager for Disciplr, Michael has a one-of-a-kind perspective on the intersection of books, publishing and technology. Michael and his family live in Colorado Springs, CO where he invests his "spare" time helping publishers solve old problems with new solutions through his consultancy, FuturePub.

Dumb content on smart devices

The original Amazon Kindle is almost seven years old and the first iPad was released more than four years ago. Plenty of other e-readers and tablets have followed and the digital content marketplace is vibrant. So why do we spend most of our time reading dumb content on smart devices?

I’m talking about ebooks, newspapers and magazines that are oftentimes nothing more than digital replica editions of the print versions. “Print under glass” is how they’re sometimes described and I think that sums it up.

The phone in your pocket contains more computing power than an Apollo spacecraft yet we’re still largely consuming content that rarely, if ever, takes advantage of the device’s capabilities.

Why?

One reason is because the old model works. People are used to reading content in a print format, so why change? More importantly, change is hard, expensive and often requires the publisher to overhaul their editorial and production process, all of which is costly and risky, particularly when the new model is unproven.

An alternate solution is to add digital capabilities in layers to the existing print format. IOW, keep your current editorial and production model in place but layer on digital content and capabilities as a post-production process. Test a few titles out, see which ones do well and invest in even more digital layering for the winners.

Curious to hear more about this? Join us next Tuesday, September 30, at 1:00PM ET for a short webinar where you’ll hear from a publisher who is already doing this. Click here to register now for this free webinar.

How print is slowly killing publishers

It’s a textbook example of The Innovator’s Dilemma. The crazy part is we all know it’s a big problem and yet very few publishers are taking evasive action.

I’m talking about the reliance on print, even at the expense of digital transformation and growth. Here are a few reasons why print is a publisher’s silent killer:

Presentation style – A newspaper is pretty much defined by what appears on the front page as well as how everything else follows it in each edition. Books aren’t that different; they have a beginning, middle and an end. Digital content, on the other hand, isn’t as rigidly defined. Have you ever reached the end of a Google News feed, for example? Publishers who have deep roots in the print world are often too focused on how the print product is presented, often allowing it to drive their digital product.

Workflow – Presentation style is, of course, closely tied to workflow. A publisher who built their editorial and production models around print is likely to apply the same existing model to digital. This is the main reason many publishers evolve from static to dynamic content. And when they experimented with digital they often overhauled their workflow with disastrous results. The problem wasn’t due to a new workflow. Rather, a product nobody wanted was created and the new workflow got tossed aside with the failed product.

“It’s all we know, what we do best” – Editorial teams that have perfected print delivery often have problems adapting to digital. It’s foreign to them and outside their comfort zone. One publisher recently told me they’re pulling digital strategies out of editorial and into a small, centralized team; publishers and editors are to think about print and print only. Meanwhile, print revenues continue to decline. It might make the editors more comfortable but it’s also got to be pretty demotivating. Now is not the time to revert to comfort zones.

Opens the door to startups – As The Innovator’s Dilemma teaches us, disruption is great for the startup and often not so kind to the incumbents. It’s actually an excellent opportunity for established publishers to engage with startups but that rarely happens. As one startup founder recently shared with me, “I get the impression the publisher wants to simply copy our technology, not partner with us.”

Print defines your brand – This is probably the biggest killer of all if your brand is directly associated with print. When consumers hear your brand name all they can think of is a print product. There’s no association with digital whatsoever. Newspapers struggle mightily with this one. The solution is tough to swallow: Create a new brand that’s built around and tightly aligned with digital. It’s OK to say “Powered by old-print-publisher”, but the main brand needs to be detached from your existing, print-centric name. 

Structured documents for science: JATS XML as canonical content format

MollyIt’s only my 7th day on the job here at PLOS as a product manager for content management. So it’s early days, but I’m starting to think about the role of JATS XML in the journal publishing process.

I come from the book-publishing world, so my immediate challenge is to get up to speed on journal publishing. And that includes learning the NISO standard JATS (Journal Archiving and Interchange Tag Suite). You may know JATS by its older name, NLM. As journal publishing folks know, JATS is used for delivering metadata, and sometimes full text, to the various journal archives.

But here’s where journal and book publishing share the same dilemma: just because XML is a critically important exchange format, is it the best authoring format these days? Should it be the canonical storage format for full text content? And how far upstream should XML be incorporated into the workflow?

Let’s look at books for a minute. The book-publishing world has standardized on an electronic delivery format of EPUB (and its cousin, MOBI). This standardization has helped publishers drill down to a shorter list of viable options for canonical source format. Even if most publishers haven’t yet jumped to adopt end-to-end HTML workflows, it’s clear to me that HTML makes a lot of sense for book publishing. Forward-thinking book publishers like O’Reilly are starting to replace their XML workflow with an HTML5/CSS3 workflow. HTML/CSS can provide a great authoring and editing experience, and then it also gets you to print and electronic delivery with a minimum of processing, handling, or conversion. (O’Reilly’s Nellie McKesson gave a presentation about this at TOC 2013.) And which technology will get the most traction and advance the most in the next few years, XML or HTML? I know which one I’m betting on.

In terms of canonical file format, journal publishing may have one less worry than book publishing, because many journals are moving away from print to focus exclusively on electronic delivery whereas most books still have a print component. Electronic journal reading—or at least article discovery—happens in a browser; therefore, HTML is the de facto principal delivery format. And as much as I’d like to think HTML is the only format that matters, I know that many readers still like to download and read articles in PDF format. But as I mentioned, spinning off attractive, readable PDF from HTML is pretty easy to automate these days. So I ask:

If XML is being used as an interchange format only, what do we gain from moving the XML piece of the workflow any further upstream from final delivery?

Well, why does anyone adopt an XML workflow? The key benefits are: platform/software independence (which HTML also provides), managing and remixing content to the node level (which is not terribly useful for journal articles), and transforming the content to a number of different output formats such as PDF, HTML, and XML (HTML5/CSS3 can be used for this transformation as well, with a bit of toolchain development work).

But XML workflows come with a hefty price tag. The obvious one is conversion, which is not just expensive, but costly in terms of the time it takes. Another downside is the learning curve for the people actually interacting with the XML—how many people should that be? In the real world, will you ever get authors, editors, and reviewers to agree to interact with their content as XML? So more likely than not, you’re either going to need to hide the fact that the underlying format is XML through a WYSIWYG-ish editor that you either buy or build (both are expensive), or you’re doing your XML conversion towards the end of the process. On a similar note, how easy is it to hire experienced XSL-FO toolchain developers? But developers who work in the world of HTML5, CSS3, and JavaScript are plentiful.

So building an entire content management system and workflow for journal publishing around XML—specifically JATS XML, which is just one delivery format, that isn’t needed until basically the end of the process—doesn’t seem like a slam-dunk to me. I should clarify that using JATS XML for defining metadata does seem like the obvious way to go. But I’m not so sure it’s a good fit to serve as the canonical storage format for the full text. One idea is to separate article metadata from the article body text, to leverage the ease-of-editing of HTML for the text itself.

What about moving HTML upstream, and focusing efforts on delivering better, more readable HTML in the browser? What about shifting focus away from old print models and toward leveraging modern browser functionality, maybe by adding inline video or interactive models, or by making math, figures, and tables easier to read and work with?

Just to throw a curve ball into the discussion, I attended Markdown for Science last weekend, where Martin Fenner and Stian Håklev led the conversation about whether it makes sense to use markdown plus Git for academic authoring and collaboration. I want to hear from as many sides of the content format conversation as possible.

So, what do YOU think?

This article was written by contributor Molly Sharp, appeared earlier on the PLOS site and has been presented here with permission of the author. Molly has worked in various content management-related roles since the late 90′s, when she led the implementation of an XML editing and production system for Sybex, a tech book publisher. Most recently, Molly was the Director of Content Management at Safari Books Online, an electronic reference library of 30,000 tech & business titles, where she created and managed a Content Team to ensure the quality of incoming content; designed and maintained content-related processes and workflows; and managed a publishing partner community of more than 100 organizations.