“Wait, You Write In A Spreadsheet?”
How a cobbled-together, in-house publishing tool evolved into a real product
It started with Keynote, actually.
I had loved Robin Sloan’s FISH and wanted to experiment with the visual sequential story as a container for explanatory news content. So myself and Newsbound’s designers created a prototype in Apple Keynote that retold the story of the Trayvon Martin shooting.
We used Keynote’s iPhone app to power the prototype and tested it, in person, with casual news consumers. The positive feedback we received emboldened us to take the next step: create another visual story in this style, but this time publish it on the web.
We looked into the possibility of just embedding our Keynote prototypes, but quickly realized that there was no easy way to do that while also retaining the build-ups and subtle animations that we had employed. Moreover, we wanted to track audience retention.
Around this time, our lead developer, Kathryn Aaker, joined the team and we began brainstorming about the quickest route to getting an embeddable prototype up on the web.
Enter the spreadsheet
Because writing in Keynote is not the most pleasurable workflow, I and writer Patrick Sharma had been using a Google spreadsheet to organize the prototype content, with each cell representing a tap forward on the part of the user.
Kathryn looked at our system and proposed building it out as a temporary CMS. After all, the spreadsheet could carry a lot of weight for us: quickly segmenting chunks of text, handling multiple users, tracking versions, and easily exporting its data.
So she dove in and added some structure to the spreadsheet, including new columns to specify images, transitions, and text formatting.
We hooked in Dropbox to handle image importing. Then came a lightweight rails app to pull the data out of the spreadsheet and convert it to json. Kathryn opted to use an open-source library, deck.js, to power the reading experience and we went with Mixpanel for analytics.
We published our first stack in late August 2012. It covered the history of political conventions and was followed by additional stacks on various wonky topics: Super PACs, the electoral college, the fiscal cliff, the rise of weaponized drones, the national debt.
Our initial priority was the reading experience. Our team of three engineers fully focused on A/B testing and optimizing features on the front-end. In the meantime, each writer and designer on our team learned how to juggle the command line and our Google spreadsheet system to assemble, preview, and publish their latest projects.
We saw great initial engagement at launch, with tens of thousands of readers spending five-plus minutes engaging with these wonky explainers. Completion rates for 2,000-word pieces regularly exceeded 60 percent.
Soon we began receiving requests for custom stacks — from news outlets, think tanks, advocacy groups, and other publishers looking for a digital container that could bridge the gap between static infographics and videos.
Pulling the spreadsheet into a web app
While we had originally aimed to produce only original content, we chose to instead work as a digital agency in 2013 and much of 2014. As our content team worked on client projects, the engineers focused on improving the reading experience. We made our player run faster and perform better on mobile screens and responsive sites. It withstood huge spikes in traffic as stacks made their way into Bill Gates’ annual letter and onto the New York Times website. In 2014, this KQED-commissioned stack was launched more than one million times.
Gradually, we streamlined the production workflow too, simplifying our unwieldy spreadsheet nomenclature and building a web app that allowed our writers and designers to easily modify and preview their content.
As more of our original and client work made it out into the world, writers and designers regularly wrote in to tell us they wanted to try our storytelling format. Many of our prospective clients — having recently hired an in-house designer themselves — told us the same thing.
This emboldened us to take the next step: releasing our backend as a licensable publishing platform. To do so, we needed to turn our utilitarian workhorse of an app into a more user-friendly product.
Leaving the spreadsheet behind
While our small product team began to build a WYSIWYG (what-you-see-is-what-you-get) version of the app, I attempted to train some of our potential users in the spreadsheet system, in the hopes of driving some early revenue.
A few users survived the learning curve, including inewsource, Homeless Hub, and the Commonwealth Fund. But it soon became clear that, for most, this setup was too intimidating and confusing and slow.
Still, this process allowed us to surface feature ideas, explore new use cases, and try out various pricing models. The resulting insights flowed into the product design of Stacker, which we’re releasing to the public this month.
Log in and you’ll notice that Stacker’s drag-and-drop interface is similar to certain slide-based tools (including our old friend Keynote). In our case, however, both the tool and its output live fully on the web. Moreover, our product is optimized around a different type of experience: a person reading a visual story on their desktop or mobile browser, not sitting in an audience and listening to a presentation.
Looking at Stacker today, what surprises me is how the spreadsheet, while essentially a clever hack, ended up informing the new design.
One thing we valued about that system, for instance, was the birds-eye view it offered of the story and its underlying components. Stacks can be complex compositions, with layered visual and text elements, driven by a variety of precisely-timed transitions. The spreadsheet allowed us to choreograph our content efficiently and we wanted to carry that higher-level view over to the new app.
The result is our layer grid, which appears below the drag-and-drop canvas. It displays which text or image elements appear where and allows the producer to extend those elements across numerous frames, adjust the z-index, and quickly move things around. It’s similar to the timeline you would encounter in audio or video software, but is based around click events rather than seconds.
The spreadsheet as a minimum viable CMS
While we stumbled into the idea of using the Google spreadsheet as a temporary CMS, several open-source publishing tools are committed to it as a backend, including Tarbell and Timeline.js. For prototypes or projects with scant engineering resources, it is a great lightweight solution. This thread on Hacker News highlights some similar, spreadsheet-powered projects floating around out there.
For me, the takeaway here is that, when building a new product, you often need to look for ways to outsource some of the work — particularly the components that aren’t user-facing. In the beginning, our editorial team needed a way to assemble stacks on their own, without constantly demanding time from our small engineering team. But our engineering team didn’t have time to build a full-fledged authoring environment — they needed to focus on the reading experience, which we were still working to validate. Moreover, it would have been incredibly risky to build a full backend at this point, before we knew if the reading experience worked. As Eric Ries says in his post on technical debt: “The biggest source of waste in new product development is building something that nobody wants.”
So goodbye, spreadsheet. You were a stalwart companion in this journey. And we’ll (kind of) miss you.
