Disclaimer: there’s nothing inherently wrong with PDFs. They work on pretty much any device, and for printing, they’re tough to beat.
But PDFs on the web are a hack. They’re born of the web’s early days when putting something online meant hardcoding in HTML. Instead of adapting content to what was then a pretty limited visual experience, we #wonkcomms types opted to produce electronic versions of print documents to post online.
Unfortunately, as the web improved, our processes didn’t. We continued to make the PDF report our central product. Most wonkcommers make noises about moving beyond the PDF, opting for blog posts, infographics, and BuzzFeed listicles. But many others continue to treat the PDF report as the “real” product.
Admittedly, our team at The Century Foundation hasn’t figured out exactly how to move beyond the PDF. But we are trying some new things. In fact, our first entry into digitally-native reports launched on March 10.
This post walks you through our process in producing the piece. (Note: it will make more sense if you see the end product first. Go ahead and take a look. We’ll wait.)
Step 1: Research
Like any wonkcomms project, everything starts with research. For this project, we paired with one of our nonresident fellows, Stefanie DeLuca, an associate professor at Johns Hopkins University. Stefanie’s latest research focuses on the Baltimore Housing Mobility Program, which provides vouchers for low-income families to move into neighborhoods with more opportunity.
Stefanie has an extensive list of academic publications, but her experience writing for a wider audience is less extensive. We decided early on to bring in Jessi Stafford as a co-author and project manager.
Because Stefanie’s research utilizes a mixture of qualitative and quantitative methods, we had access to a rich set of materials including audio recordings and participant interview transcripts. Stefanie’s research assistant selected five case studies and forwarded interview transcripts and photos for those participants.
There was a lot of stuff.
We decided to focus on two families, adding in supplemental quotes from other program participants to bolster the story.
Step 2: Brainstorming
We’d picked out our families. We knew their basic stories. And we knew the basic policy points. But we didn’t want to use a straightforward narrative. After all, we were writing about real people embedded in real places. We wanted to use the web to show our story, not just tell it.
So we did what anyone putting together a digital-first project would do.
We got out a whole bunch of Post-It notes.
At this stage, we determined what media would tell each part of the story best. We knew, for example, that Stefanie should be the star of the policy section, so we decided to show her policy prescriptions with a short video. We also knew we wanted to compare several programs that were similar to the one Stefanie was studying. That lent itself naturally to some sort of infographic.
The main theme is about neighborhoods, so we decided to include photos of different city blocks and provide data about those neighborhoods with a series of maps.
Finally, we knew we wanted to showcase images of our feature families to supplement their stories.
We then mapped out a basic story structure alongside the types of media we would need to produce.
Because we’re capturing this process in narrative form, these next two bits are going to look nice and neat and organized.
That’s…not as true as we’d like it to be.
In future iterations, we plan to insert a new step after brainstorming. This is what we’ll call the “concept and pitch” stage. In this stage, we’ll work out the basic design elements (i.e. photos or illustrations), determine the voice and tone for the piece, and sketch out the general creative theme.
For example, we wanted to show how the Baltimore program changed how participating families viewed the world. That idea of changing perspectives drove our design elements, from the video in the opener, to the color palette, to pull-quotes in handwritten text.
But many of those targets were still moving until the publication date. (Hey, it was our first time.) In the next round, we will lock in the creative concept earlier. To self-enforce that plan, we will conduct a formal pitch session with the researcher(s) involved in the process.
Step 3a: Writing
We entered the writing phase without a clear concept for the final product, which created its own set of challenges. For starters, we were unclear on the narrative voice. We bounced between sounding too journalistic (i.e., mostly narrative with a bit of policy thrown in) and sounding too academic (i.e., mostly policy with a few anecdotes about participants). We spent a couple of weeks really wrestling with the fact that every approach felt disjointed.
Finally, we embraced the disjointedness. We chose a structure allowing us to jump around in time, deliberately changing the voice for policy sections (written in Stefanie’s voice) and narrative sections (using a more conversational tone). It’s here, too, that we finally settled on changing perspectives as the central thesis of the piece.
Step 3b: Design and Web Architecture
Next, our design and development teams went to work building the digital framework.
Creatavist is built explicitly for creating long-form digital narratives. That means it has many features we’ve come to associate with “long-form digital” (e.g., parallax images, full-width inline video, chapter divisions) right out of the box. Even more intriguing, for those who are trying to get on board with the Create Once, Publish Everywhere model, Creatavist also lets you push your content directly to various e-book formats. You can even choose to include (or not include) different chapters in different publication types. So you could, for example, include a chapter with an interactive chart in the web version but then substitute a flat image in the ebook version.
That said, Creatavist is an amazing platform, particularly for shops that are (like ours) too small to realistically build a bespoke web app for every report.
It was also at this stage when we realized we would not be able to use actual photos of the families in our study. Study participants are anonymous, and under Johns Hopkins’ ethics rules, identifiable images were prohibited. Illustrations, however, were perfectly permissible. So Abby Grimshaw, our designer, broke out her paints and began creating the illustrations you see in the piece.
Step 4: Gathering Assets
With the narrative drafted, the web architecture mostly developed, and many of the additional pieces of content (maps and the infographic) largely in-hand, we needed only to collect a few additional assets, most notably, filming Stefanie and shooting video footage of Baltimore.
Fortunately, Baltimore is an easy train ride from New York. Stefanie took Jessi and Abby around the city for filming and photography. You can find film versions of Stefanie’s policy prescriptions, as well as her audio clip on housing opportunity, in the final piece.
Step 5: Assembling, Editing, and Browser Testing
With all the pieces in place, we sent the project off for a final round–okay, a few “final” rounds–of editing. We discovered there isn’t a particularly elegant way to edit inside Creatavist, so we ended up doing a low-tech workaround: we pulled the text into a Word document (shudder), then conducted a final round of edits in the screen version over the phone.
The last step was to conduct in-house browser testing. Unsurprisingly, we had some issues in Internet Explorer. Somewhat more surprisingly, we found the video wouldn’t play in iOS devices. Chris implemented some server-side browser-sniffing to swap in a static image for the video in iOS.
Here are the big ones.
- Scope your project. You’ve got a really talented team. And it’s your first time out-of-the-gate. You’ll be tempted to cram in every feature you’ve ever learned how to build. Your story probably doesn’t need that, and you’ll drive yourself insane trying to produce all of it.
- Lock in your concept early. Your project is going to have to pass through a lot of hands (researchers, authors, editors, designers, and developers at a minimum). Some of those stages can happen concurrently–but only if everyone already understands what you’re trying to create.
- Set deadlines. Jessi made extensive use of our team’s project management software to schedule every piece of the project. That said…
- Be agile. Some things that seem like good ideas early on won’t pan out and will need to be replaced. Or people will get sick and you’ll need workarounds. Which brings us to…
- Build in extra time. We had one internal deadline 10 days before we published the project. We would have done well to build in additional milestones, and to include a larger window at the end. That way if, say, half your team ends up out sick in the last few days before publication, you’re still safe.