Integrating dynamic data into narrative storytelling

When the Storytelling Studio and Curbed embarked on “10 streets that define America” together in June, no part of this project was set in stone. Curbed came in with a thesis statement and a list of cities they wanted to include in the feature, but were open and willing to collaborate with us in all aspects of the creation process. In our weekly meetings, we discussed everything from narrative focus to content organization and, eventually, to data integration.

By collaborating closely, we created opportunities for the data to be integrated into and enhance the narrative, rather than be treated as an afterthought.

Start early

As I began reading the first few city drafts, I realized that many of the pieces included various facts that would benefit from being explored in a visual way. The Burlington draft, for example, included a passage explaining how teachers and staff at the local elementary school communicate with new students and parents in nine different languages on a day-to-day basis, as a result of the diversity in the area. Now that I knew nine languages were spoken, I wanted to know what and how prevalent each of them were.

This was when it hit me that we didn’t necessarily need to provide the same baseline statistics for each city, nor did we need to compare the cities to one another. The entire thesis for this narrative was shaped around the diversity between, as well as encapsulated within, each of these cities. If we were going to use data at all, we ought to use it in a way that would highlight the unique aspects of each city.

That said, even if you’re interested in a particular topic, such as diversity or public transportation, looking at statistics in text or chart format often doesn’t mean as much unless you have a baseline to compare it to. What if we could give users something to compare these statistics against? What if we let them compare the city data to data specific to where they live?

Make it seamless

When I suggested integrating user-specific, location-based data into the city narratives, everyone was intrigued. After discussing the idea, we collectively agreed that using data in this way would add significant value to the narrative, but only if executed in a particular way. We discussed the following:

1. The data and location components should not feel like they are interrupting the narrative.
2. The barrier to entry for obtaining location-specific data should be very low and only be requested of the user once.

Using Geo IP to create a frictionless experience

When a user first enters the story, the application uses a Geo IP service to determine the user’s current zip code and populates the story with the relevant data. If I’m at the Vox Media office and decide to visit this piece, for example, the application will automatically populate the narrative with data for 10044, the zip code associated with my current IP address.

My intention was to create a frictionless experience, where the users could engage with this interactive component as much or as little as they so chose.

Users are able to change the zip code used to populate the story in a specified area on the cover page and at any point where an interactive data element is included in the narrative.

Enable users to share their customized experience

We wanted users to be able to easily share their version of the story with others, so whenever the zip code is changed (or originally set), the page url and all sharing links are updated to reflect this change.

By setting it up this way, whenever a user is referred to one of the pages through a url that has been shared, the story will automatically populate with data for the zip code that the person sharing the page had set. This shared zip code takes precedence over the zip code associated with the user’s current geolocated IP address.

For example, here’s a tweet from the Curbed Philly account:

If you click on the link included in this tweet, the story will populate with data for 19103, the zip code in downtown Philadelphia where Rittenhouse Square is located.

Brainstorm, investigate, revisit

After agreeing on how this data integration would function, both the Curbed team and I began collaborating in a Google doc containing potential data ideas for each city. We then prioritized our ideas for each, coming up with alternates and fallbacks for datasets that may not be available on a granular enough level for the zip code specific comparison we planned to implement.

Because we needed to be able to provide a variety of statistics for what could potentially be any given zip code in the United States, I decided to use Census Reporter, a Knight News Challenge-funded project, as my main data source. The Census Reporter API provides data for a majority of the interactions we hoped to include on the city, county, and most importantly, zip code level.

Know when to concede

Unfortunately (though understandably), Census Reporter doesn’t provide any historical data, which knocked out a few of our top choices. Ideally we would have included an interaction focusing on the influx of immigrants in Burlington over the past few years and booms in population growth that both Denver and Louisville have experienced recently. Though we could have manually downloaded this data from the United States Census Bureau’s American FactFinder, we would not have been able to provide the companion statistics for the user’s zip code.

After determining exactly which statistics we had at our disposal via the API, we came up with alternate options for a few cities, swapping out the Burlington immigration idea with a chart depicting the percentage breakdown of languages spoken at home, and chose to remove interactive data points from Denver and Louisville.

Validation through user testing

When we user tested this, three out of five users said that they would be interested in sharing their customized stories with others. All of the users said that they found the dynamic zip code functionality interesting and thought that it added to the piece.