There has been a great deal of debate in the last few days about why mainstream news organizations in general and newspapers in particular don’t link out to sources from their stories. Many participants in the debate have asserted that this is because news sites still fear sending people away. Or they don’t “get it,” i.e. they don’t understand how the web works, or the value of linking, or even what a link is.
Perhaps that was true to a larger extent in the past. But having spent a lot of time working with newsrooms, I can tell you that by and large this is no longer case. The problem is not one of attitude or ignorance, but rather the more mundane yet still hugely significant problem of technology and workflow. And it’s a much bigger problem than most people discussing the issue realize — so much so that the solution has not been obvious.
Fortunately, there is a solution. But first, for the sake of broader understanding, let’s fully flesh out the problem.
Here’s how Brian Boyer at the Chicago Tribune explained it:
At the Chicago Tribune, workflows and CMSs are print-centric. In our newsroom, a reporter writes in Microsoft Word that’s got some fancy hooks to a publishing workflow. It goes to an editor, then copy, etc., and finally to the pagination system for flowing into the paper.
Only after that process is complete does a web producer see the content. They’ve got so many things to wrangle that it would be unfair to expect the producer to read and grok each and every story published to the web to add links.
The solution seems obvious — switch to a web-centric workflow by creating all of the content in the web CMS first. Most web CMSs make it easy to add links, or at least much easier than newspaper print editorial systems, many of which don’t even accept HTML.
While many newsrooms do now publish breaking news on the web first, there are two big reasons why newspaper newsrooms can’t easily ask all of their reporters to write all of their stories in the web CMS first:
1. Web CMSs don’t handle multi-stage editorial workflows
As Brian pointed out, after a reporter finishes a story, it needs to go to an editor and then to a copy editor. Most Web CMSs are not designed to handle this workflow. You can’t set story status to track where is in the workflow. Editors can’t be notified that stories are ready for review, or are ready for copy editing. Reporters can’t be notified that revisions are required. You can’t manage story assignments. You can’t customize the workflow in any way.
I’ve actually heard many web-native editorial operations complain about this limitation, even in a flexible CMS like WordPress. Daniel Bachhuber actually developed a plugin for WordPress, called EditFlow, to solve this workflow problem (which is great, if you use WordPress as your primary web CMS, which most newspapers don’t).
But why on earth, you might ask, do these newsrooms need all of this editorial process? Why do they need layers of editors and copy editors? Most web-native publishers let their writers post directly to web. If there are mistakes, they can just update the content in real time, fix typos, post corrections, etc.
That’s how web publishing works. But it’s not how print publishing works.
In print, you only get one chance to get it right. Publishing content as a continuously updated process works great when you can update in real time, but not when you have to wait until the next day to post the correction, at which point it’s really too late.
And there’s another big difference between publishing on print and publishing on the web — finite space. If a reporter files a story, and there’s not enough space for it, somebody needs to make it fit on the page. Because the web has infinite space, web CMSs were not designed to accommodate a workflow that requires making the content fit the available space.
Lastly, there’s one more major difference between a print workflow and a web workflow — press deadline. You’ve got to print the newspaper, and everything needs to be ready to go by the time the presses roll. On the web, you can publish on a rolling basis, 24/7. But for print, it only happens once a day, which by its nature requires a more complex, coordinated process.
It’s certainly open to debate how many editorial layers are really necessary for creating the print product. Many newsrooms have been forced to reduce the number of layers as the result of cost reduction cutbacks. But it’s simply not practical for most newsrooms to produce the print product without a system that can handle an editorial workflow with some degree of sophistication.
2. Web CMSs don’t support the print layout process
Creating the newspaper print product is, fundamentally, about traditional desktop publishing. Layout and design is done typically in InDesign or Quark. And most newspaper workflows are based on a process for easily getting content into page layout.
A key function of the print editorial system is to flow content, properly formatted, onto pages in InDesign and Quark. These systems can also sync edits made on the designed page (e.g. making it fit) back into the database. Many of these systems handle high resolution photos, also necessary for print, but not the web.
Bottom line — newspapers can’t simply throw out their print editorial systems and just use their web CMS for everything, simply because it’s easier (or even possible) to create links in the web CMS.
That brings us to another seemingly obvious solution: Why not create all content in the web CMS first, then simply import it into the print editorial system for the print workflow.
Newsrooms actually have a term for this: Reverse publishing
You could make a strong argument that it’s time to “reverse the polarity” of publishing, as newsrooms transform for a digital future.
There’s just one problem — there’s no way to get content from the website into the print editorial system. Most print CMSs can’t import RSS feeds, because they were all designed based on the assumption that content flows in the other direction. Print editorial systems are typically desktop applications that don’t natively connect to the web. (This, by the way, is why it’s so difficult for web publishers to deliver content to newspaper partners — subject for another post.)
The newsrooms that do publish web first are typically reduced to copying and pasting content from the web CMS into the print editorial system.
So even if a newsroom reverses the polarity of its publishing priorities, the technology doesn’t make it easy.
Until now.
The Solution
Publish2 has solved this problem, with a very counterintuitive approach. We’ve developed support for delivering content into print editorial systems using the import function that these systems were designed to use — receiving content from a traditional newswire.
To deliver content into print editorial systems, Publish2 uses the formats and delivery mechanisms that are completely unknown outside of newspaper newsrooms and foreign to anyone who only publishes on the web (ANPA, NITF, I won’t bore you with the details).
Using the Publish2 Print-Digital Integration module, newspapers are able to create content in the web CMS, publish web and digital first, and then easily flow all the content into the print editorial system. We strip out the HTML for print, so reporters can link as much as they want in the web version. We can also deliver the content into the archiving system.
And we can do it all without any change to the existing systems, and without the significant expense of throwing out the old system and buying a new one. So there’s no throwing out the baby with the bathwater to adopt a digital first publishing workflow. This solution also has the benefit of freeing up web producers from a lot of copy/pasting and other manual workflow to spend more creating original web content and features.
The result is that the only barrier to change is a willingness to change. And that is a barrier that most newsrooms, as a matter of survival, have already overcome.