Understanding the data

Q. Could you talk a little bit about how this piece came to be? What was the process like for approaching this project? Could you walk me through a little of the data collection process and who was on the team?

Beckie Supiano: As this story explains, we started out planning to use the net price by income data to compare colleges’ priorities when it comes to student aid. But then, as I started reporting out the story, I realized that not all of the colleges were reporting their data in the same way, so that comparison wouldn’t work the way we’d planned. This became instead a piece about what’s wrong with the data.

Once we knew that the national data wouldn’t allow for the comparisons we’d wanted to make, the next issue was getting more detailed data from a college or two to illustrate the problem we had discovered. The University of Notre Dame shared those details with us.

At first, our team was me and a couple of editors. Once we realized that the story would work much better as a data visualization, we also worked with our data team, most notably Soo, who thought of and built the scroll structure to walk readers through the story and also animated the key graphic that shows why it matters which way the colleges report their numbers. Ron Coddington was also a key player as he did all of the illustrations.

How did you decide to focus on one school (Notre Dame)?

Supiano: We needed a way to show the big difference between the two ways colleges were reporting their numbers. Having one college share both versions of their data was one way to do that. I reached out to a number of colleges and Notre Dame was willing to both share the data and explain it in a fair bit of detail.

Designing the experience

What was the design process like? I really enjoyed the feeling of narration, but also felt myself wanting to go deeper on some aspects of the story. Are there ways for readers to continue exploring your data or follow related stories?

Soo Oh: Beckie sat with the data team and walked us through her discoveries. We had Notre Dame’s data, so we figured a big picture explanation with a case study could be an effective way to tell the story. After that, I thought about the various ways we could present it. The data was a little hard to understand at first. In fact, it was only when I was in the middle of prepping the presentation that I fully understood what was going on. So it was important that we could walk a reader through the information step by step, the way Beckie explained the story to the data team.

I had this idea that the presentation would be kind of like a motion graphic video, except you’d scroll through it like a traditional web page. There are a lot of benefits to the long scroll — namely, that it shows your reading position relative to the page length and can also act as a scrubber. And having those illustrations tell part of the story meant we could get rid of a lot of the finaid jargon that complicated the big picture.

At some point in the design process, Beckie and I sat down in a big group to hash out the narrative with some editors and our art director. We walked through the outline and started solidifying the illustrations for each slide.

As for related stories, Beckie wrote two follow-up posts (here and here) that weren’t yet published when the story went live. At the bottom of the explainer, we had a couple other finaid/data-related links, which I swapped out with Beckie’s new posts after they were published.

Were there any particular design or coding challenges posed by this project?

Oh: Visualizing the 877 students in Notre Dame’s Fall 2012 freshman class was the first part of the presentation I worked on. You had to see how all these students were categorized, then re-categorized, to understand how the federal data could be so misleading. One of the data tables Notre Dame sent over had the total count of students by income group using the two different methodologies. I turned that into a CSV with each row representing an individual student’s income group by both federal and institutional methodologies, then used D3.js to parse the CSV and create the visual.

I struggled with how to build the scroll-triggered transitions between all of the slides. The solution seems really obvious to me now, but at the time, I was literally building a slide, then moving elements within the slide, then destroying the backgrounds on major transitions. This was such a terrible idea, creating and recreating and destroying HTML nodes, and I totally knew it, but of course I wasted my time with it for a day because I didn’t know what else to do. The trick was CSS transitions, and that solution came to me, as these things tend to do, late in the office when everyone had already left for the night. I defined a Slide object with the components I wanted visible and scooted the rest of the elements off stage. You can see in the picture below how that might have looked.

For mobile, we ended up using the swipe event and did a horizontal slideshow presentation. It just looked and felt better than scrolling. I learned that phone browsers hate moving and resizing elements simultaneously (my phone froze several times during testing), so I simplified the animations there. We also decided to get rid of the big 877-student visual. As we tested on various devices, there was a consensus that reducing it to fit into a phone-sized view just wasn’t translating correctly. We focused on the shifting prices, and Beckie worked with the editors to rewrite the text for mobile. The story is the same, but the text for each slide in that section is a little different depending on whether you’re viewing on a smaller screen or not.

Lessons learned

What were your takeaways from the project? Any lessons to share with other news organizations or that you expect will inform future projects?

Supiano: One takeaway for me was the power of this story form. The piece we have explains what is going on with the data so much better than I could have with just words. This team approach to a story is very involved and time consuming, but there’s a real payoff to that. Another takeaway as a reporter is that data is often just the starting point for a story. Sometimes, data answers our questions, and that’s great. But sometimes they raise questions instead, and getting to the bottom of those can be a lot of fun and, I hope, a good service to readers.

Oh: All of the above, and don’t forget to double or triple the time that you think you’ll need for editing and browser/device testing.