Linking and journalism: The Workflow issue

There was an interesting discussion about linking and journalism amongst a number of journalists in North America. Mathew Ingram of GigaOm and  Alex Byers, a web producer for Politico in Washington, both collected the conversation using Storify. It covers a lot of well worn territory in this debate, and I’m not going to rehash it.

However, one issue in this debate focused on the workflow and content management systems. New York Times editor Patrick LaForge said:

[blackbirdpie url=”!/palafo/status/70668697051725824″]

Workflow and how that is coded into the CMS is a huge issue for newspapers. For two years when I was at The Guardian, most of my work was on our blogging platform, Movable Type. Movable Type had scaling issues, as did almost every blogging platform back in 2006 when I started at The Guardian. However, Movable Type and other blogging platforms also make it ridiculously easy easy to create content – rich, heavily linked multimedia content. It was so much easier than anything I had ever used, especially when coupled with easy to use production tools such as Ecto and MarsEdit.

However, due to the scaling problems with Movable Type, The Guardian moved its blogging onto its main content management system. We didn’t have a choice. We had outgrown Movable Type. However, I’m being diplomatic in the extreme when I say that the new CMS lacked the ease of content creation and publishing that I had grown accustomed to with Movable Type and WordPress. Furthermore, there was an internal conflict over whether to use the web tools or the print tools to create content, and in the end, the print tools won out. The politics of print versus the web played out even in the tools we used to create content. That was an even more jarring move. It was like trying to create a web story with movable type, and I’m not talking about the blogging platform.

Most newspaper CMSes are more WordPerfect from the 1980s than WordPress. That’s why you have journalism outfits setting up blogs on Tumblr. Creating content on tools like Tumblr is like falling off a bike instead of trying to write caligraphy with a telephone pole. You can build a robust, advanced content management system without making the tools to create content so piggishly ugly, bewilderingly confusing and user surly. However, newspapers code their workflows into their CMSes. The problem is that their workflows aren’t fit for modern purpose.

Newspaper newsroom workflow is still print-centric, apart from a very few exceptions. The rhythm of the day, the focus of the tools and much of the thinking is still for that one deadline every day, when the newspaper goes to the presses. From this post by Doc Searls on news organisations linking to sources (or not linking as the case may be), see this comment from Brian Boyer about his shop, The Chicago Tribune:

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.

When I got here a couple years ago, a fresh-faced web native, I assumed many of the similar ideas proposed above. “Why don’t they link?? It’s so *easy* to link!”

I’m not saying this isn’t broken. It is terribly broken, but it’s the way things are. Until newspapers adopt web-first systems, we’re stuck.

Wow, that’s a really effed up workflow by 2011 standards, but a lot of newspaper newsrooms operate on some variation of that theme. It’s an industrial workflow operating in a digital age. It’s really only down to ‘that’s the way we’ve always done it’ thinking that allows such a patently inefficient process to persist. Seriously, has no one really thought that it’s easier to export plain text from HTML than to bolt on a bunch of links, images and the odd YouTube video to a text story destined for a dead tree? Want to cut some costs and increase the quality of your product? Sort out your outdated industrial workflow, save a lot of money, hire more journalists and improve your web and print products. Simples. (Well, after sorting out your workflow, hire a digital sales team, and then you can hire even more journalists. That’s a post for another time.)

23 thoughts on “Linking and journalism: The Workflow issue

  1. What I’d now love to hear talked about is how this can be fixed. Are we all just doomed until us web-natives eventually rise to roles of prominence in these newsrooms? Do you have any thoughts on that?

  2. There’s no question, I think, that the workflow issue is the critical one. And, as it’s not one that can be easily rectified. Like you point out, a rearranging of editorial processes and software would go a long way in the battle against linklessness, but that’s a fairly tall order.

    I don’t think it’s as simple as ‘export[ing] plain text from HTML,’ though — at least from a process perspective. Say you export a story from a web CMS for print. Then it gets updated. Do you re-export? What if it’s been cut down for size? What if you want part of the update but not all of it? Where does copy-editing fit in?

    I’m with you in general, but I think there are trunk and branch issues to consider. There needs to be a good way to update stories without forcing producers (print, web or otherwise) to do the same work over and over again.

    And while were on the subject, thanks for the Storify link 😉

  3. There are solutions for this problem, but they are as much cultural as they are technological.

    First, fix the wastage that comes from doing content over several times – for print, for web, for tablets. That predicates a complete overhaul of the editorial workflow, and with it, a redefinition of some of the roles in the newsroom.

    Second, move to XML based content creation. Don’t create content with embedded print layout tags. Take your XML content (known in the trade as ‘channel neutral’), and then transform with CSS to the appropriate medium.

    Principles are very simple, savings are big (see Daily Telegraph in the UK), and the journey to get there painful and disruptive.

    These are all interim steps too, by the way. If it weren’t for print (!), then much of the complexity would be removed, and blogging tools would suitable, assuming they could scale properly. However, a large newsroom still needs some workflow (even for pure digital) to make sure that commissioning and subbing has been done.

  4. Than you for this intelligent, informed post. We have a first-rate homegrown Web CMS, WordPress for blogs and a built-out third-party print publishing system that updates every couple of years. In practice, we have a split work flow, with some content going straight to Web (or blog) then to the print system, and other content going the traditional way. Our goal is a true “Web First” system, which requires CMS enhancements now under way, and development takes time. Alas, this is an incredibly boring explanation compared to the inaccurate and condescending “print dinosaurs just don’t get the Web.”

  5. Patrick, that’s great to hear and it’s not boring. I can’t speak for others, but I don’t think that all newspaper folks are dinosaurs who don’t get the web. The reality is just that print often gets prioritized over online, is that not accurate? There are reasons for why this happens and sometimes some of them are valid. And of course the real issue is that online and print aren’t seen as one seamless part of the whole. They are often separated into their own ghettos and this is truly the crux of the problem.

  6. I believe there is an answer to the “how can we solve the workflow” problem. It is a model I proposed and started now nearly 7 months ago: Liquid Newsroom. It supports on-demand writing, spontaneous gathering and co-editing and real-time news allowing reader feedback. It is an open innovation project, so the process of its development is public and it is not build in stealth mode. What we need is a News3.0 infrastructure which uses all players in the media/news market right now: aggregators, news outlets, real-time messaging (Twitter), … You’re invited 😉
    – Best, Steffen Konrath

  7. Have you tried writing using MarkDown? it’s a markup language invented by John Gruber. It allows you to write in easily readable text that can then be parses into HTML or ready for print.

    There are many applications that can parse the language and a few iPads apps that support it too. It shouldn’t be difficult to build this into any workflow.

  8. As I noted in my comment on Doc Searls story, I find the workflow argument compelling, true, and ultimately meaningless. By compelling and true, I mean that newsroom research has consistently found that news routines, workplace technologies, journalist-source relations, the bureaucracies of newsrooms, etc exercise a surprisingly large influence on the production of news. It’s not surprising that CMS and workflows play a large role in determining when newspapers do and do not link.

    But by ultimately meaningless, I mean, “so what”? It seems comforting for journalists to blame their CMS setups for their various linking difficulties, but newsrooms face logistical and workflow challenges all the time. Some they chose to address and fix. Others they ignore. Newspapers have made strenuous efforts to do various things online (like adjust workflow routines in order to manage the imposition of reader paywalls for instance, just to name one example), but doing other things are less important to them.

    [Perhaps the NYT should have taken a fraction of the however many millions of dollars they spent putting up their paywall and devoted it to better organizing their socio-technical workflow. But, actually, better organizing the workflow is not an organizational priority to the same degree that erecting a paywall is.]

    When pressed, newspaper representatives implicitly acknowledge the truth of this line of thinking by falling back on arguments like: “the value of links are unclear,” “readers don’t care about them,” “linking is web orthodoxy,” and so on. This gets us into the realm of organizational and occupational culture. There are plenty of things newspapers do for reasons of professional culture (needing multiple quotes to confirm a fact as “true” is only one example of newspaper orthodoxy that actually makes little sense to anyone not socialized within a newsroom), but these practices, of course, are not questioned by journalists. It’s only when encountering an alien cultural system (conventions and cultures of linking, for instance) that charges of orthodoxy are raised.

    In short: the fault, dear journalists, lies not in the CMS, but ourselves.

  9. CS – Regarding your comment about the NYT: We did set aside resources for this top priority. Our antiquated Web CMS has been replaced in the last year, and the dual newsroom management structure for Web and print was abolished in January. Of course there are always lingering cultural issues in a large newsroom with hundreds of people, but at this point the main challenges are training and ensuring the staffing to support all of our platforms, including print. Interestingly, we are finding that the technology and the workflow changes do in fact drive cultural change.

  10. Until such a point that digital is more profitable, most newsrooms will always be geared up for print first (At the moment, even if the supposed dark days the industry is going through, most publishers are still turning profits).

    As a digital editor at a regional paper, I know there is only so much that can be done within the confines of the system – and there is relatively little editorial staff can do to alter the stance of the firm as a whole (let alone have any input in the overhaul of CMS).

    Ultimately, most places seldom link for the simple reason that the majority of journalists, like the majority of the population, are not particularly savvy when it comes to HTML. If you’re not technically minded, it is a daunting medium.

    Until publishers (not journalists, seeing as the decision will be taken well above their heads) invest in software which hides the technology from the user, linking will also be at best an after thought.

  11. This is a good discussion about technologies that could be and solutions we’d like to have, but Zootopian’s comments are the most spot-on.

  12. Thanks to James for mentioning the Daily Telegraph example. Are there any other case studies of newsrooms that are doing this well?

  13. “Ultimately, most places seldom link for the simple reason that the majority of journalists, like the majority of the population, are not particularly savvy when it comes to HTML. If you’re not technically minded, it is a daunting medium. ”

    It is literally one button in a WYSIWYG editor. Can you bold text? Then you can link.

    Maybe linking isn’t something they routinely consider when filing a story, but that’s a cultural or workflow issue, per above. I don’t buy the ‘too technical’ argument for a second. Surely someone at your org can show them what button to press and where to paste.

  14. i’ve been recommending that newsrooms setup zemanta for journalist as a sort of web editorial training wheel approach to exposing them to the differences between traditional & digital workflow – linking, tagging, related content and media are all net new requirements for transitioning from pulp to bits – from a newsroom technical perspective beginning to understand semantic technologies and specifically iptc/rnews will be very useful…

    two helpful links are:

  15. The print/web challenge is a bit more complex than this. There are inherent challenges in simultaneously preparing content for two (or more) vastly different publishing channels. Print is static, space-bound, and supports text and images. The web is – well you know. The nature of print being static means that there is intense focus on that snapshot in time.

    Take a simple example: A story is fully edited and published on the web and then moves into a print system. It’s now partly an translation problem: What does an H2 on the web turn to in print when it moves over? Yes, easy. But the story also references a video that is embedded on the page, a screenshot of a Tweet, has 25 images, and links to some third party sources. You can’t really reference the video in print in the same manner, and you probably can’t show all 25 images, just 1. Depending on how the article references the supporting content you may have to do some tweaking. So at that point the story will have to be edited separately for print. Also maybe the story is too long to fit on the page so you have to edit it down 2 inches for fit. At that point you have forked the content and have separate destination-specific versions. Annoying, but probably mostly manageable. Now add to that the *real world* where stories evolve and are re-edited or corrected, sometimes dozens of times, and up to the minute that the print edition closes. You can make these changes in 2 places or you can follow best practice and make them in the source content only and then push the content back to print. What happens to all the print-specific changes that were made? Right.

    The easiest way to deal with most of this is to tightly structure the web content and make it truly display-agnostic. Sorry, no inline photos, no embedded You Tube, none of the things that many people love about a rich web experience in the first place (yes, there are ways to solve much of this this). Also no divergence of the print version of a story form the web version. Sorry, the web story has to suffer from the space limitations of the print version. If anything, the print organizations that are most attached to a rich web experience are going to have the most integration complexity, not the dinosaurs who don’t care about the web and are attached to “dead trees”.

  16. Thanks for all of the comments, and I think this is an important conversation that I’m glad to have. Zootopian, having started my career at a 14,000 circulation regional newspaper in western Kansas, I know the challenges there. However, you say linking it too technically challenging for journalists. Really? As I said to Alex on Twitter, you say can’t, and I hear won’t.

    Why web-first at the local and regional level? Ask John Paton, who is resurrecting the Journal Register Company. He’s pushing low-cost tools and encouraging innovation. The company exceeded his $40m profit target by a million, and all employees get a week extra pay as a bonus, apart from execs. (“They have a bonus plan, and it’s enough already,” Paton said.)

    Brad, I’ll agree that it’s a bit more complex than this, but having worked at The BBC, which began publishing via the kind of channel-neutral platform back in early part of the last decade, it’s a problem others have solved. The BBC CMS allowed us to create content and publish it to six platforms simultaneously. James provides an example, The Telegraph, from a print perspective. You’re trying to make the case for a print-centric workflow, and there are a number of organisations that have solved (a long time ago) the seemingly intractable problems you present. You’re trying too hard. 😉

    In terms of digital making money, that’s the little note at the end. In the news organisations that I’m working with now, the successful ones have a sales team focused on digital. Digital shouldn’t be a sales sweetener for print. It’s a product (should be products) that should be sold on its own. Thanks for the comments, and I’ll follow up again.

  17. Kevin – this isn’t about the workflow being print-centric. As long as there is a print component in the workflow there are going to be complications that you can’t ignore. Because print has physical space limitations that you have to honor, does that make your workflow print-centric?

  18. Patrick, a lot of that is down to editorial policies at the BBC. When I was there (1998-2006), we didn’t do in-line linking in the main news website. When I ‘blogged’ the 2004 US election for the BBC, the links came after the text. They also, by policy, didn’t do deep linking on the chance that the link might move. The internal debate about linking at the BBC went on for years and still comes up from time to time.

  19. Brad, I think that Scott Karp at Publish2 has a pretty good solution for this that allows for digital first while also dealing with the complexities of print workflow. It makes a lot of sense.

    As for my workflow (1998-2006 at the BBC and 2006-2010 at The Guardian) has been multi-platform since the late 90s. It’s a matter of priorities. Fortunately, I’m technically and editorially proficient enough to work around the limitations imposed by most workflows.

  20. Publish2 only seems to solve half the problem – arguably the more simple half of the problem. Getting content from a web CMS to flow into a print system is relatively simple, and I would guess that any modern print news organization could handle the technical aspects of this without much challenge. I think the true challenges come from: 1) offering an authoring environment that competes with the standard, MS Word (sorry no web-based solution comes close… yet) and 2) dealing with the timing issues that come with editing a story for print layout and fit at the same time that it is evolving on the live version.

  21. Oh and sorry for diverging so much from the original topic of linking on the web!

Comments are closed.