How to Make It Easy for Newspapers to Link on the Web

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.)

Charms & Pendants: charms,
Earrings: gold and silver earrings,
Rings: Diamond Rings.

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.

20 thoughts on “How to Make It Easy for Newspapers to Link on the Web”

  1. Just so I fully understand this, any newsroom could implement this today no matter what print and/or online CMS they are currently using?

  2. How do you handle updates? What if I publish a story to the web, import it using your module to a print CMS, and then writethru the web file? Do I have to re-import to print? What if I’ve made print-specific edits to the version I’ve imported? Any way to preserve those?

    I’m not sure you’ve got a perfect solution, but it’s certainly a useful start AND is available to newspapers right now with minimal effort. Would love to see this catch on — perhaps at first with the more fluid and less-dinosaury college media?

  3. @Alex, Publish2 works like a wire service. When you update a story in the web CMS, we automatically update the version on Publish2, and then automatically push out a new version to the print CMS. The print CMS sees the new version that same as it sees updated versions moved through a traditional wire service. Most print CMSs import new versions of updated stories, so it would not overwrite the version where you made print specific edits.

    We’d love to work with college media.

  4. Hmm. Sorry, I’m not convinced. The argument being made here is that print and web systems can do their jobs in isolation, and you get the advantages of the specialised system in each case.
    Reverse publishing is fine, and using the wire feed as a back-door makes some sense. But: moving the content around is less than half the problem. True convergence thinks about news planning, content commissioning, deadline tracking (for all media), a single subbing desk, and visibility about how content has been used/reused between media. You simply don’t get this from joining two systems together.
    Further, there is more granularity than print/web. Think about mobile and tablets – they add a third and forth dimension. Perhaps the web CMS can do a stripped down mobile site, but I’m betting it can’t do a digital replica of the paper – because that comes from PDFs (or better yet SVGs) of your PRINT layout…
    Lastly, there is a question of legacy. No argument that replacing print systems is a huge, expensive and culturally painful task. But, until an organisation makes the shift to a more modern CMS, it is stuck with the inflexibility of it’s print system – and- perhaps more importantly, the journalistic and cultural attitudes that go with it. ‘You can take the journalist out of the CMS, but you can’t take print out of the journalist…’

    Ultimately, I think this is a question of scale – smaller newsrooms have less culture to break, and fewer costs (and revenue) to make these sorts of large changes. In which case an interim model might work, but then, you might argue that they should cease print entirely, remove those costs, as well as the necessity for a toolset that can handle print.

  5. @James What newsrooms need is bridge to get from here to there. Most can’t make the leap from where they are directly to a unified system any more than they can “cease print entirely, remove those costs, as well as the necessity for a toolset that can handle print.” Because of course if they cease print, they also lose the revenue that is still funding the operation. Instead, they need to maximize cash flow from print to invest in their digital future.

  6. Scott – I understand the revenue problems intimately. The point I am making (polemically), is that the CMS debate is a catalyst for structural change. A bridging solution may be appropriate in some cases, but in others it hinders the wholesale shifts that are needed to reform attitude, workflow, production costs, and print vs web first models.

  7. @James Creating all content in the web CMS first, to publish on the web first, even with the legacy print CMS still in place, would be a pretty significant change, don’t you think?

  8. Sure, and that’s part of my point. I’m advocating (for large organisations), that a shift in tools is a huge exercise. So, why do half a job, and end up with a solution that is still fundamentally compromised in terms of delivering convergence? Clearly, there are other factors (cost primarily), and each newsroom will have to do that analysis for itself.
    And it’s the fact that it still is a compromised solution that leads to my polemic about stopping printing. Consider this: at some point, some publishers will be forced to either close, or reduce costs (declining circ, ad yields etc). At that point, their print revenues don’t support their operating costs in any case, so going digital only becomes more viable, even appealing. When that happens, the printing plant they use has one fewer customer, as do the distributors. Suddenly, every other publisher that uses that shared facility sees their costs rise, precipitating a chain reaction. It might not happen all at once, but it does mean that there will come a time when not printing, is a competitive advantage.
    In that scenario, having a bridged solution where you haven’t converged your systems is good – you haven’t spent a truckload on modernising the print CMS, but you’ve got to be willing to accept that you are facing a digital only future at some stage, in order to make that call.
    However, most large publishers can’t shut down print operations, and therefore MUST look to the day when their printing costs increase. And the solution is – save costs on production (subbing, layout, etc), by rationalising jobs and functions between print, web, tablet and mobile. At that point, a properly converged system makes good sense.

  9. @James One of the key challenges, if not *the* key challenge, is that newspapers don’t know when when or whether an all digital future will come. To make a massive investment in a new unified CMS that does print and digital (if such exists), newspapers need to be certain that a digital only future will *never* come.

    With a bridge solution, they can invest the print cash flow where there is more certainty of opportunity, e.g. tablet apps the create deeply engaging content consumption experiences that an be better monetized than the desktop web. And the beauty of a bridge solution is can be implemented very quickly — you could argue that learning to adapt nimbly is the real asset, rather than starting over from scratch.

    It’s kind of like agile software development vs. the traditional waterfall model.

  10. Scott,

    Yes- it is like agile not waterfall. But the other way round! Agile predicates quick delivery and reuse where possible. A converged CMS allows for parallelism of workflow, and minimal rehandling for print and web, rather the than sequential, and duplicate creation, subbing and layout that is demanded by separated systems- and resembles a waterfall process.

    No argument that 2 systems are cheaper. And, in the absence of hard data about whether it’s viable to stop printing, how does a publisher choose the best path? It’s cost benefit. If the cost of a large convergence project yields sufficient benefits in efficiency, then it may be worth doing. A bridging problem is a smaller step, but in my view preserves entrenched attitudes to print vs web, and doesn’t address the underlying issues that most print newsrooms are pretty inefficient.

    The two approaches result in different cultural outcomes. To me, taking a bridging approach treats the symptoms rather than the cause. Each publisher is going to need to decide for themselves what the best approach is, but I don’t accept that connecting two systems and reverse publishing achieves the same results as an editorial workflow designed for channel neutrality. But for some, the results may be enough.

  11. @James I was using the software development metaphor to describe *how* newsrooms change — in an agile, iterative way vs a master planned waterfall approach. And I disagree that having the entire newsroom create content in the web CMS, for the web, first, is not a significant cultural change. It is, and it’s one that can easily happen today.

    There is also evidence that convergence is not the panacea you’re making it out to be. Enabling digital to remain independent and agile, while still enabling the print product to be produced, may be the more effective path to transformation.

  12. If I can jump in here… I’ve gotta agree with Scott on this one. James, I totally understand where you’re coming from, but I think an incremental step towards where I think we all want to be is better than no step at all. And I can’t see why if a publisher implements this solution today while she is still putting out a print and online product, she couldn’t keep working seamlessly even if she no longer has the print product one day. I also agree that even though we all wistfully wish for convergence, it might not be a true reality; that Guardian piece Scott linked makes excellent points.

  13. I’m finding this article and subsequent comments fascinating as the web industries are beginning to grapple with a related issue. By all current estimates, mobile readership (of the web) is expected to surpass desktop readership within a few years. But developing  mobile optimised content shares some of the challenges you describe. We need to alter content for different contexts (eg. screen sizes, device capabilities). When done properly, this extends quite deep into the editorial and data input process. How do you specify ‘alternate’ images for an article in your average CMS? How do you mark certain passages as dominant and others as non-critical (content that can safely be removed on small screen devices without losing the narrative of the piece).

    Many of us are advocating a ‘mobile first’ approach, not only to development but to content production and tools are at this stage sorely lacking.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>