In the 20th century, the most pressing process question for newspapers was how to capture the news of the day and distribute it via print. The highly choreographed ritual of putting out the paper became known as The Daily Miracle. Even today, the definitive thud of a newspaper landing on your doorstep each morning requires a workflow nimble enough to handle the uncertainty of news, the whims of advertisers, and the vagaries of weather.

After more than a century of refinement, this system is a picture of efficiency — at least when you consider the inherently chaotic nature of journalism.

Delivering news online is still in its infancy, and the shift from finite, physical delivery to continuous, multiplatform distribution requires a process re-examination. The miracle of news delivery must occur much more frequently than once a day.

The Washington Post, like every other newspaper, is actively working on revamping its processes to fit the needs of this wild, new landscape.

A first step

The Post publishes 500 staff-written stories each day. Naturally, the reporters and editors who work on those pieces would like to see them heavily promoted.

For the editors who decide which of those stories deserve homepage play or a tweet, life can, at times, feel like being on the wrong end of an overactive tennis ball machine. So. Much. Incoming.

Before we built WebSked, reporters and editors pitched their stories for promotion in a variety of ways: in person, via HipChat, and, especially, in an unrelenting torrent of emails.

This was not a terribly efficient system.

Receiving pitches via email is suboptimal for a number of reasons:

  • Once someone on the receiving team has evaluated the pitch, he or she needs to REPLY ALL to notify the group in order to avoid redundant work. This guarantees most pitches generate at least two group emails.
  • Email inboxes are single threaded, so if you're an editor trying to run coverage for the latest ISIS attack, you're probably not interested in the weekend arts preview right now, thank you very much.
  • Everyone on the receiving team gets bombarded, even on their days off.
  • If the story gets a significant update, the section editor needs to REPLY ALL again to let the pitch recipients know.

In fall 2014, we set out to build a digital planning tool that would allow curators running the homepage, social platforms, and apps to find and promote the best of the Post’s offerings. We launched the beta to a small group of editors running the Post’s homepage a few months later.

The core feature of the application at the time was the ability to pitch stories to curated plans, called “Platforms.” Section editors found their desks’ best work and filled out a short form indicating where the story should be featured (for example, the homepage or social media pages) and why the story is worthy of promotion (e.g., “exclusive to the Post”).

Editors on the Social team, for example, curate the list of the stories they’re interested in promoting by marking these pitches as “watching” or “saving.” Once they’ve tweeted out a story or shared it with the Post’s nearly 5 million Facebook followers, the editor then marks the pitch as “used” and includes any relevant details, such as “retweeted reporter from main account, shared on Facebook.”

As editors quickly mark which stories they’ve used, the newsroom amasses a robust record for each article. In the past, homepage editors had to write lengthy handoff notes, detailing all the stories they had used over the course of their shift. Now, the incoming homepage editor can quickly scan the list of stories marked “used” from the past few hours to get up to speed.

This first version of WebSked was primarily a list of stories, ordered by publish date (actual, scheduled, or planned).

As illustrated here, each story listing includes metadata about the story, such as the author, section, and current state in the workflow pipeline. WebSked also allows anyone in the newsroom to read in-progress drafts of stories. Each update to a story in the content management system is propagated almost immediately to WebSked, allowing editors to evaluate a story based on its current form.

In order to place in-progress stories into the time-ordered stream of content, we had to add a new metadata field to the story: the planned publish time. We updated the various content management systems in use at the Post, such as Méthode and WordPress, to require reporters to state when their piece will be published online.

The addition of the planned publish date was the key data point which made it possible for us to build a truly comprehensive tool.

Adding a new, semi-required field to the various content management systems in use at the Post required training, patience and a bit of arm-twisting. Unsurprisingly, being told that your story won’t be considered for the homepage unless you use the new system is a motivating factor for many reporters.

Lab baby

Reports on research and innovation labs often focus on their boldest and most creative solutions. As they should, probably. But sometimes it’s the smaller bore work which ends up having the biggest impact in the end.

When we set out to start building WebSked, a digital designer pointed out that a lot of the story organization concepts we were working through had already been addressed by the Post's design research team, WPNYC.

The Manhattan-based crew’s main focus was to rethink the suite of tools in use at the Post, and they had already spent a considerable amount of time investigating how to best organize the large volume of stories.

We forked an early prototype of a larger system they were dreaming up and adapted it to our needs.

From the start, we focused on making the application easy to use. Many content management and publishing systems are an ugly thicket of dropdowns, but we aimed to build something more intuitive.

The first iteration of WebSked was elegant and easy to use, at least in comparison to existing publishing and planning tools. We continued work on the tool and kept in touch with our newsroom users via Intercom. They sent us bug reports and a surplus of product ideas, many of which we implemented in subsequent releases.

We later expanded WebSked to handle newsroom workflow, which we implemented as a task creation and assignment system. The task system was built with section and copy editing in mind, but is flexible enough for other applications. One early use at the Post was flagging stories for the comments moderation team. Expanding the tasks functionality to meet more newsroom use cases is on the product roadmap.

Expanding beyond the Post

A few months into using WebSked at the Post, it became clear from our conversations with other news organizations that there was significant interest in the tool. In order to make WebSked part of the Arc Publishing suite, we first had to untangle the dependencies and assumptions we had hard-coded in for the Post.

There were obvious elements, such as company name and messaging app integrations, but we quickly realized that many other elements would be need to be customizable.

WebSked allows organizations to define their workflow and publish statuses. Instead of shipping the tool with a new way of working baked in, WebSked allows journalists to map their existing concepts into configurable lists. This eases onboarding, while still allowing users to see and filter on these attributes.

While WebSked permits news organizations to customize an increasing number of attributes, some concepts are too central to the idea of WebSked to allow customization. For example, pitch reactions, such as “watching,” “saving,” and “used,” cannot be edited by users. We determined that this was a core feature, and making it configurable would likely render the app much less useful.

While most of the configuration decisions are binary, we opted for a hybrid solution for task statuses. As the name suggests, these statuses are used to indicate the current state of a task.

An organization can set up additional statuses, but they must keep these first five. Retaining these statuses allows the WebSked user interface to surface the contextually-appropriate button.

For example:

If editors at a newspaper want additional task statuses, they can easily add them:

By linking these states, WebSked is able to simplify Sue’s job. It’s a small win, but this timesaver adds up over the course of a shift. If our Arc Publishing clients find these baked-in statuses to be an issue, we’ll investigate building a more robust workflow engine that allow each organization to establish the links between statuses. In the meantime, this looks to be a solid compromise between convenience and customizability.

Over the course of the next days and weeks, we’ll publish additional articles outlining specific challenges we’ve faced and explore in greater detail where WebSked is headed. Next up: a look making WebSked available in Spanish for our customers in South America.

While WebSked is still a young product, it is quickly growing into a key component for managing stories for promotion, coverage planning, and task management at the Post and for our Arc Publishing partners. With it, the more-than-daily miracle is a bit more achievable.

Thanks to Joseph Blair, Alex Byrnes, Willi Ehreiser, Gregory Engel, Brendan Magee, and Matt Monahan for providing feedback on this post.