The New, Convoluted Life Cycle Of A Newspaper Story

News must be really hard to follow for an everyday consumer of a newspaper website. First tweets go out, sometimes with no links to additional coverage. Then a few grafs go up on a blog, followed by additional updates, either to the top of that post or as new posts. Eventually, a print story gets started, which is posted through an entirely different workflow onto a different-looking story page. This version is usually written as an hourglass-style narrative, following typical print conventions. For the rest of the day, new updates start going to this story rather than the original blog post. Having a hard time following? Here's a graphic to help: As a reader, this is confusing because: I don't know where to start or end When I jump into the story somewhere in the middle gray area, I don't know where to go to get previous coverage or the full picture To continue following the story, I don't know where to look When I look at all this content as a whole, I don't know where the newest information is. A convolution of publishing platforms Unlike a blog like TechCrunch, for example, a newspaper is publishing to multiple platforms. TechCrunch has one platform, one story type: blog posts. Newspapers are the only type of publishing company to have the distinct differentiation of "print stories" (which are posted to the web) vs. "blog posts" vs. "web updates" (to the print stories). The different platforms, web CMS and print CMS, have different workflows associated with them. The big questions I see popping up in newsrooms like my own are: Do we tweet if we don't have a link to direct users to? Do we send an email alert if we don't have a link to direct users to? When do we write a story as a blog post vs. a web story? When do we append an update to the top of a post vs. writing a new post? When do we stop writing blog post updates and switch over to the print story? After switching to a print story, do subsequent updates go to the print story or in the blog? How do we update the blog posts to direct users to the newest information in the print story? How do we instituionalize the act of adding hyperlinks within previous coverage to newest coverage? How the hell do we make this all make sense to our users? A few use cases of places doing it right, or at least something closer to right BBC Live Coverage When news about the Norway shooters broke a few months ago, The BBC set up a live coverage center where live updates came in a stream in the form of text, photos and blog posts. The dashboard contained updates in realtime of different types. Although it sounds similar to Twitter, the benefit is that BBC owned the platform . They could include updates longer than 140 characters, control formatting, and optionally include tweets, too. The reason this coverage style works: Quick snippets of information come in the form of updates rather than having to be integrated into a blog post somewhere It's easy for the users to digest. They always know what the newest information is. The Los Angeles Times The LAT model, though less elegant than BBC's approach, is closer to what news organizations can pull off today if they need to. The hub of breaking news at The LA Times falls, from my observations, into LA Now -- their local news blog. They're very specific about the headlines around news topics: They each include keywords. I observed during the Seal Beach shootings in September -- when a man killed eight people at a hair salon near Los Angeles -- that each blog post contained a set of hand-curated links within each post to direct users to the most recent coverage. This approach is effective because it creates a central spot for all coverage around a topic and users have a way of finding more information through related links, which go into each blog post. At The Seattle Times, we tried to copy that model by using a shortcode in each post about Viadoom (our major highway closure in Seattle) that we updated with the most recent links about the topic. That way, if a user landed on an older post, they would still find the most recent coverage. But what this still doesn't address is at which point to start the "print" slug, whether to put subsequent updates with the "print" story online, or into a blog. And of course, the big question: How to connect the dots for readers. Practical guidelines you can apply right now In my mind, these are a few guidelines you can use to help inform your newsroom about how the workflow should function for breaking news: Always start in a blog form -- i.e., your quickest way of publishing. If the update is significant enough that, in print, it would merit its own new headline, then create a new blog post, rather than an update to an older post. Try to build in an automated way of linking to the most recent coverage. In our CMS, this would mean building an ESI. In WordPress, you could use a shortcode. Some other CMSes will probably have an equivalent component that could be updated universally across stories. There should be no rush to point to the print story unless it provides a significantly different angle than what the blog posts said. Ideally, in a crazy world that many newsrooms might not be ready for yet, the entire web CMS is the same as the blogging CMS, and story types don't differ based on "posts" and "print stories," and the print stories don't necessarily have to be on the web because they're not made for the web-- they're made to be read on a piece of dead tree with no additional context. For big news items, there's more incentive to build out some kind of landing page that pulls in all the content related to a certain topic, but doing that for all the day-to-day stories isn't sustainable. However, it is these small day-to-day stories that need to have the threads connected because these stories constitute a bulk of the coverage at our news organizations. Ideally, we'd need to create a way to institutionalize the interconnectedness of our coverage. Ditching the episodic storytelling mode As Jay Rosen and crew brought up at an SXSW "Future of Context" panel, our news often falls into episodic spurts. We cover stories through the convention of writing "stories" like we would for print. When there's new information, we add a few sentences to the top of the post to tell the new information, then summarize the rest of the story at the bottom. We basically have the same stories repurposed over and over again with a few snippets of new information at the top. See the image below for an example -- the highlighted portions are the redundant parts of an ongoing story for six Seattle Times articles. Episodic storytelling is based on the model we used for telling stories when print papers came out once/day and that was our only chance to tell the full story and the only medium for getting the full context about a story. We don't have to do that on the web, but we won't change how we tell stories on the web while that print medium still exists. So we have to find a happy balance between the two, while thinking ahead to how that model might look in a future when print isn't the same print is today. Easier said than done, right? Re-birthing the concept of wiki-style news If we used a Wiki approach to chronicle news, the full story exists in one spot, and it's constantly re-written to reflect the most recent version of the story. Readers are always seeing the most recent version, perhaps with the newest information highlighted in a way that's easy to see. The revision history could be public-facing, so those who want to see a stream of updates have the option of doing so. This would: Allow readers to always see the most recent version of the story, always directed at the same URL, rather than a different URL every day that basically repeats yesterday's information with a few new nuggets With a public-facing revision history, users can always see what the newest information is in the story. This can currently be accomplished by appending "Update 11/20/11 at 3 p.m.:" to the top of a post, but then the story becomes an incohesive jumble, rather than being a narrative story. This serves all types of users: Those who have been following a story and want the quick hits, or the users who are just hearing about the issue for the first time and want to read about it from top to bottom. Of course, a wiki-style of news wouldn't have to be as bland as Wikipedia. There is an elegant way of building it that looks good, is easy to filter and tag, can feature multimedia elements and photos, and allows for RSS subscription to updates and email newsletters. In a sense, they could be extended topic pages, with the latest nugget of news always at the top. Each topic could have sub-pages and sub-sections. It could look something like the event dashboards that The New York Times has built for The Oscars (aka the "Second Screen," which we've written about here). *** These are all just ideas and a starting point, of course. If you have better ideas or thoughts on how to create a more cohesive story life cycle, we'd love to hear from you in the comments or in your own post.

Fishbowl

The New, Convoluted Life Cycle Of A Newspaper Story

Lauren Rabaino

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Lauren Rabaino