We have a saying in Systems: our tools should serve us, not the other way around.
This hasn’t always been the case.
Our newsroom interacts most frequently with two tools: Google Drive and our Content Management System, Wagtail. We use Google Drive to store gathered documents, draft stories and track assignments. Our CMS is how we upload stories to our website, ubyssey.ca.
Years ago, we had a custom CMS called Dispatch. But as time passed, it grew more and more cumbersome to use. We eventually migrated to Wagtail, a popular open-source CMS used by organizations as varied as NASA’s Jet Propulsion Laboratory and Google. As great as Wagtail is, however, the default UI isn’t set up for the high-volume and collaborative aspects of a newsroom.
The Wagtail-Google Drive interaction has been a bane on editors’ workflow for years. Senior editors now laugh as newer editors practice the ritualistic sigh that immediately precedes logging into our website’s backend.
Here’s what the process looks like.
Every story starts as a Google document. The first part of every draft is what we call the assignment memo: notes from an editor about what the story is, which sources to speak to, what ethical issues are likely to come up and when the first draft is due. Once that’s sent, reporters start their research, conduct interviews and get to writing.
While that’s going on, an editor keeps track of all their active assignments in a section-specific Google spreadsheet. If someone — a concerned senior editor, a time-pressed editorial designer or a curious reporter — wants to know what’s going on, they prowl the Shared Drive to locate an idiosyncratically-organized spreadsheet. After the reporting is over, the section editor usually receives a message on Slack that it's time to start editing. When content editing is done, the link to the story doc is posted in a Slack channel and cued for copyediting.
Content and copyediting are only half the battle. In fact, they’re more like a tenth. When you’re working in Google Docs, there’s no point haggling over where to place photos in the body of the story — we can’t just copy-paste that into our website; photos are uploaded in Wagtail. Should the headline appear on top of the feature image or to the left? That’s also a Wagtail issue. Metadata? Don’t get us started. There’s no point even thinking about that until it’s time for Wagtail.
And that right there is the essence of the problem. Our current workflow systemically separates newswriting, visual journalism and product design from each other. We aren’t able to actually think about certain key aspects of our journalism according to logical workflows because our tools deny us those opportunities, at least with any degree of convenience.
Asking Google Docs to behave like a CMS was a lost cause. It’s not built for publishing. Wagtail was the CMS we had, but unmodified, it was no longer the CMS our journalism — and ultimately, our readers — deserved. As of late, our CMS was (1) a harrowing interactive experience that wasted several hours per person per week, made worse by (2) a lack of common, newsroom-wide knowledge of what stories were being worked on.
While our newspaper might be named after the Homeric epic, there’s no reason digital publishing has to be an odyssey of its own. Our solution: enter, Stove.
Right now, we’ve developed two tools for Stove: an assignment manager and a manuscript editor.
An assignment manager is critical for our newsroom’s operation. We need to be able to see what stories we’re working on, who they’re assigned to and what stage they’re at. This is currently in the form of a Google Sheet, which is entirely separate from where editors communicate with reporters, write, edit and upload stories. Because updating the assignment manager is an extra step, our spreadsheet is neglected and often out of date.
We needed something to create common knowledge of who was working on what, when and how. Google Sheets might be fine for managing the content of smaller Instagram accounts, but the multi-stage and multi-path life of a news story can’t be apprehended by your standard pivot table. And when you’re writing or editing on a deadline — an actual deadline, not one where you get five per cent off per day — you have next to no time for extra click burden, window-switching, or opening and closing split views.
To fix this, we integrated the assignment manager directly into Stove. In the same place that editors assign stories, provide ethical guidance and write articles, they’ll be able to set deadlines and share the story’s status with the rest of the newsroom. When a reporter files a draft for editing, everyone will be able to see the status of the story — which is especially helpful for our Visuals and Product divisions when they are determining what stories need graphics, are suitable for a podcast or should have a custom digital design.
Because we are developing the assignment manager from scratch, we can serve the workflow of our editors, rather than forcing editors to adapt to our system. When our sports editor told us his section used multiple deadlines for each article, we added that functionality directly into the assignment manager.
Our assignment manager will be rolling out for Reportage later this week, with Visuals and Product assignments coming in September.
The manuscript editor is our Google Docs replacement where we’ll write and edit stories. We had two main requirements for the manuscript editor: it should look like the published article as you are writing, and multiple reporters should be able to simultaneously write, suggest and comment.
Our website and articles are built using templated blocks, like text, images and audio, each with a unique series of fields, like captions, credits and sizing. In Stove, we render the blocks sequentially — the same way we do for readers.
To edit those blocks, we looked into rich-text editors and landed on ProseMirror, which is used by organizations like The New York Times. Using ProseMirror, we added — in addition to regular text editing capabilities — comments, suggestions and different interfaces to edit each type of block.
When an editor adds an image, there are dropdowns for sizing and positioning. When an editor changes a block, it updates in real time for everyone working on the story. This collaboration is critical for our newsroom as we work on tight deadlines with every story having multiple contributors.
The introduction of Stove represents an early step in our slow transition away from the Google suite of products. While our website (including Stove) still runs on Google Cloud servers, we hope to move to a Canadian cloud provider in the coming years. Technical sovereignty and control over our data are becoming more important to our reporting as large technology companies like Google increasingly align themselves with political leaders hostile to journalists.
Stove is great, but we’re only just getting started. The Systems department is planning many projects over the coming year: website change monitoring, interview transcription, a notification system, newspaper games and more. This is all in service of our newsroom and our readers. If this work interests you, we’ll be recruiting Systems developers soon.
We also might as well explain why it's called Stove. We had trialled several other names around the office when, at one point, with half the newsroom present, one of us — Spencer — grew bemused with his suggestions being rejected while less-impressive options received nods. He shouted, “We might as well call it Stove!”
People practically cried ‘eureka!’ “It’s because we’re cooking,” they joshed.
Spencer resisted, at first. “We can’t call it that,” he repeated in every Product meeting.
After a few weeks of campaigning, and some administrative sleight of hand while he and the Editor-in-Chief were on a road trip, Spencer acquiesced. Stove was born, and with it a new era of our editorial process.
