This is part of “The Guts” series, where I’ll be finding cool projects and tracking down how it was made. This series will reach across all platforms, so if you see an awesome design project and want to know more about it, send it my way! You can email me at email@example.com or find me on Twitter.
The Miami Herald published a huge project on the Florida Department of Children and Families failures with child welfare this weekend. It was titled Innocents Lost, and it chronicled the hundreds of children who died even after the state was warned they were in danger. It is a sad, but very important project. The Herald’s developer Lazaro Gamio takes us behind the scenes of the design and production.
I noticed your use of a logo while the page was loading. Was this the first time you’ve implemented this?
We’ve implemented something like that before in other projects, namely our Rick Scott jobs project with Tampa Bay, which had a generic loading gif. Our custom stories are built on the client side with jQuery, so we want readers to see the page once it’s done being constructed. For this project, we wanted to use the load gate as a way to both brand all the assets and to serve as a transition between stories. There are also some stories, like the overview, where I load the project’s database to build an interactive map on the fly. The database is a json file that’s about 1 MB, so without the loading gate, the reader might be sitting there for while staring at an incomplete page, especially in cases where the user’s connection is slower.
The organization of the project is based on a landing page that features all the different parts. Was there an editorial decision to let the readers explore as they wish or was there some hesitation in not giving them an official starting point?
A landing page was a must-have for us. Not necessarily because we wanted it to serve as a point of entry, but because we have so many assets and need to keep it all organized. It serves as a place where this project will live forever, and we can reference it every time we cover child welfare. As far as a ‘starting point,’ I think the overview story is definitely our starting point, but the series is porous in the sense of where people are coming from. Someone might come to read one of the stories from Twitter or Facebook or from our homepage, and in that context, the landing page is useless, so we spent an extremely long time working on the navigation that occurs on the story level. We have previous and next tabs, as well as a menu of stories at the bottom of the page and a menu to other assets on the top left.
The use of reverse type with a black background and white text definitely works for the tone of the story. Did you have a discussion about its readability or strain on the eye?
We made the decision to use white type on black solely to match the tone of the story and set it apart from our regular template. As far as readability, the issue of black on white and white on black isn’t so much about color, but about contrast. The white I use for paragraph text is actually #cdcdcd and the black background is one level up from black at #111111. If I would have used pure black and white, the type would be pretty unreadable, so I spent a lot time picking the shades of gray to create a pleasant reading experience.
With the color palette, did you ever wish you could have incorporated more color for contrast? Such as in the graphics?
We made a very conscious choice to limit color wherever possible. We really only use red as a navigational aid, and even then we use it sparingly. The main objective in designing that way was to get out of the way and have the story and photography be front and center.
How long were you working on this project? What did you find to be the most challenging part of production?
I got put on this project in the middle of September, while it was still being reported, and the database was getting built. I worked on it on and off for this whole time, until this last month, when it became all I did. The most challenging part of the project was definitely the database, not only from a design perspective, but also from a data quality perspective. We handled data for 477 cases, and for each case, we had a plethora of attributes that were used for mostly reporting purposes, and then some that had to get cleaned up for reader consumption. Each record also has a story and a set of documents that correspond to it. It’s just a massive amount of data, and it all had to be standardized, cleaned up and kept track of. We also designed the database so it could fit in a coverage context; when you read the stories, children’s names are linked to their file in the database. We also link to subsets of the data, like deaths in a given year. It was very laborious to set up the infrastructure to make that possible.
How closely were you working with the reporters and editors? What was the biggest struggle or biggest accomplishment there?
I worked directly with them on a daily basis. I helped run numbers from the database for the series, so I had a lot of contact with the reporters on how things should be entered. They also provided a lot of input on what type of information should be displayed. Working closely with them gave me a really good feel for the subject matter, which really helped inform my design decisions for the project.
What did you learn through this process? What types of things would you like to see or implement in the future?
This project was the first time we’ve given a custom treatment to so many stories at the same time, so I definitely refined our process to be able to do these pretty quickly. This is also the first time we’ve treated a series like an app: the data for the stories powers the series homepage and navigation, and we even made a simple API to call in the different parts of the series on our custom homepage display. This project serves as the foundation for how we’re going to handle series from now on.