Designing for the Story—Michael Grant

In the initial project meeting, our team was briefed on nuances of the story and data delivered to us by Connotate, a data-extraction company hired to dig up the information we needed. The total budget specified that we’d produce an overview story with four accompanying stories on various findings, charts, data mapping, and a slew of yet-to-be-shot photo assignments.

Since we’d designed and developed last year’s report, the first question asked by editorial was if we would use last year’s layout, to which I replied… probably not. We decided instead to embark on a design project to make the stories easier to read and share.

As we began our development, many pieces of the story were in flux. The assets weren’t going to be delivered in any particular order, so we needed a design that would accommodate our story ideas—and not be a doozy to scale down from desktop to mobile-device dimensions. I sketched and produced lo-fi designs using Illustrator, where I could easily emulate and explore design devices I thought would help tell the story. I did most of the design scaffolding using a very early version of copy.

One design idea that came from a conversation with Aaron was to tease the next story when the user reaches the end of the current story—and then bring it into view with a click. I designed with that in mind, while Aaron tackled implementation. The result was that we were able to break up the story without breaking the narrative flow.

The design evolved into a combination of large, engaging headlines and color blocks coupled with photo grids and airy body type. These elements combined created good flow and helps set a reading pace while providing various entry points into the package.

Templates & Prototypes

We built this project using a template we wrote called Ingleside. It’s a Flask project template meant for rapid prototyping and deployment. It’s very similar to NPR Visual’s app template, though not nearly as robust. Having templates makes collaborative coding a lot easier because we can separate our portions of the project into individual files that we combine in the end.

I was able to hand off my concepts to Maegan Clawges complete with a defined grid from which to build. When prototyping was complete, we switched to making small code edits and implementing unforeseen design tweaks in order to ensure visual consistency.

Building the Story—Aaron Williams

When discussing this project, I was inspired by the mapping techniques I noticed at the New York Times. Their project, The Most Detailed Maps You’ll See From the Midterm Elections, had some of the most beautiful maps I had ever seen. I loved the colors, the interactivity and how well they complemented the rest of the New York Times interface. It got me wondering if our next mapping project could forgo the traditional slippy maps seen in many newsrooms and build something that not only fit the context of the story but that also fit the design around it.

Vector Tiles

I’ve often used tools like Leaflet, Mapbox, and CartoDB to design maps for news graphics. They’re great tools with wide adoption. Yet, there aren’t many basemap designs you can use for your projects unless you design them yourself or pay more for custom maps. In my research, I found that vector tiles provided a fantastic way to create custom maps. I also discovered Mapzen, an open-source mapping lab that provides a vector tile API for developers. What are vector tiles? From Mapzen’s website:

Simply put, vector tiles are squares of math. Instead of a web server sending you a pre-drawn image tile, a vector tile contains the [OpenStreetMap] geometry for a particular part of the earth, delivered on demand. It contains instructions on what can be drawn, rather than something already drawn and styled.“

Read more about vector tiles on Mapzen’s Vector Tile Service page.

OpenStreetMap (OSM) is a community-driven, open-source project aimed at creating free and open map data. Mapzen and OSM allowed us to create the map as we saw fit.

With the tool and the data for the map available it was time to build. We used d3.js and a d3.js plugin called d3.geo.tile() to render Mapzen’s OSM data similarly to how Leaflet renders tiles. d3.js author Mike Bostock has a nice map demo that uses vector tiles to render the city of San Francisco.

Again, vector tiles are powerful because you now have complete control of the map’s position and aesthetic. Michael and I sat down once we got the map figured out and began to design different combinations of colors based around his design. By assigning the attributes OSM provides as HTML classes, e.g. park, highway, minor_road, major_road, we could now use CSS to style our map.

The accompanying CSS:

 path { fill: none; stroke: #e0e0e0; stroke-linejoin: round; stroke-linecap: round; }
 .park, .nature_reserve, .wood, .protected-land { }
 .ocean { fill: #F2F3F4; stroke: #F2F3F4; }
 .major_road { }
 .minor_road { }
 .highway { stroke: #CFCFCF; stroke-width: 1.5px; }
 .rail { }
 .buildings path { stroke: none; }

Final Map with CSS for Neighborhoods

d3.js provides scales you can use to map your data into bucket ranges. Once again, I found a Bostock demo that helped us create the choropleth we wanted for the map. We used CSS to style the buckets which provided fantastic flexibility on color schemes as I designed the map.

Chronicle graphic artist John Blanchard designed the neighborhood blocks with Google’s My Maps program based on Airbnb’s neighborhood boundaries since they differed from the ones the city defines. I exported the .KML file, transformed the KML into a shapefile with QGIS and then into efficient topojson with Shpscape.

This was a simple workflow that we repeated throughout the project as neighborhoods adjusted. Finally, we combined our geographic file (the topojson) with our table of Airbnb data and created the final topojson file used in the graphic.

Additional accompanying CSS:

.neighborhood {
 fill: #FDB605;
 fill-opacity: 0.6;
 stroke: #C38701;

&:hover, &.active {
 fill-opacity: 0.9;
 cursor: pointer;
 }

&.q0–8 { stroke: white; fill:rgb(255,255,204); transition-property: fill; transition-duration: 2s; }
 &.q1–8 { stroke: white; fill:rgb(255,237,160); transition-property: fill; transition-duration: 2s; }
 &.q2–8 { stroke: white; fill:rgb(254,217,118); transition-property: fill; transition-duration: 2s; }
 &.q3–8 { stroke: white; fill:rgb(254,178,76); transition-property: fill; transition-duration: 2s; }
 &.q4–8 { stroke: white; fill:rgb(253,141,60); transition-property: fill; transition-duration: 2s; }
 &.q5–8 { stroke: white; fill:rgb(252,78,42); transition-property: fill; transition-duration: 2s; }
 &.q6–8 { stroke: white; fill:rgb(227,26,28); transition-property: fill; transition-duration: 2s; }
 &.q7–8 { stroke: white; fill:rgb(177,0,38); transition-property: fill; transition-duration: 2s; }
}

With the map done, it was back to adding the project content into our template.

Integrating Content—Maegan Clawges

As Michael finished up design mockups, I (Maegan) began prototyping his concepts in HTML/CSS. The implementation was fairly straightforward until we began replacing filler content with live elements. The package included many different types of content, each requiring special treatment.

Each story had some combination of photos, graphics, or interactive maps, so I developed a set of templates based on the nature of the content. We stored the content in JSON and then loaded it dynamically into the page, which made it easy to rearrange content. On a technical level, this meant using the number of elements in each story’s photo array to determine the layout. We had templates for items displayed inline with the text, offset to the right, and full width. Other design decisions, such as the accent color for each story, were also stored in the JSON on a per story basis.

It was very helpful that I owned both the templating system and the placement of content on the page because I was able to read the stories and understand the content needs for each. As a digital journalist, I often feel that one of my unspoken skills is piecing together many components to make a cohesive story. In this particular case, some sections were focused solely on numbers analysis and needed extensive graphic explanation. Others profiled individual players in the story of Airbnb in San Francisco and were better suited for photo spreads. It was important to weave these two story forms into each other, and I spent a fair bit of time early on thinking about the flow of the story.

As content became available, I reviewed it for fit into the digital design. One early example of this process was headline structure—the print headlines were a bit long to be placed over the headline photos. I went back and forth with the editor to lighten up the headlines and move some of the heavier words to the subheads. As we approached our deadline, editing to fit the digital environment became more and more rushed. It is so important to get content early when working in an unpredictable environment like the web.

I also did a fair bit of work on the charts after we received them from the print graphics team. We had been given printouts of the charts a week in advance, but did not receive the final digital versions until a couple of days before our deadline. I quickly realized that the color scheme, styling, and spacing on the charts would stick out like a sore thumb within our design. I quickly threw the charts back into Adobe Illustrator and inserted our colors, fonts, and spacing proportions to preserve the consistency.

If I had to do it again, I would have asked for a rougher version of the charts earlier in the development process. I ended up re-styling them so much that it was not necessary to have the final print versions. We inserted them as SVG files to open the text up to page searches, highlighting and copying. However, this messed with our font styles on some browsers and devices. Receiving the content so late definitely cut down on our time to troubleshoot small bugs like that.

We Did It

The Airbnb Effect is one of the most successful online stories for the Chronicle to date. Our Interactive Desk was able to work across the project simultaneously and lean on each others’ strengths. If you’d like to learn about the work we’re doing over here, feel free to reach out to us.