When the web lets good journalism down

5:12 am by Heather Billings. Filed under: Information Design

I was lucky enough to spend part of last week in San Francisco at Techraking 2012, an event geared toward journ-curious geeks and tech-curious journos. (Many thanks to David Cohn for organizing it!) I was struck, as I always am at geek-focused journalism events, by the lack of focus on design in the storytelling and web production process. In fairness, David had a designer scheduled, but lost him at the last minute. Lauren Rabaino and I spent several minutes examining the package that the designer was to have critiqued. My notes on that are edited, fleshed out, and written below. I have no recollection of which of these are hers, mine, or ours (nor do I see the necessity of designating). But I think it’s a useful study in exactly what a disservice our websites can do to our journalism.

(Note: I have nothing but the greatest respect for the journalists who sweated over this. This only serves as an example of a much larger problem that I see going largely unaddressed in journalism thanks in part to a lack of emphasis on design, in part to one-size-fits-all solutions.)

Wheels of Fortune: Buy Here Pay Here auto dealers

Ken Bensinger was a Pulitzer finalist in 2010 for his coverage of the flaw that caused Toyotas to accelerate without warning. His talent shines in the Wheels of Fortune series as well. He does a fantastic job of explaining a questionable business practice that often fleeces those who can least afford it.

This is, however, also an example of how excellent journalism can fail miserably on the web. I’m going to rant another time (SOON) about the flaws of content management systems and generic solutions, but for now all I’ll say is that the LAT’s CMS is at least partly to blame for the poor presentation of this rich reporting. Example: When I first saw this, all I saw were the DocumentCloud resources. I didn’t understand why these weren’t explained better. It took some hunting to realize that there were incredibly in-depth, painstaking stories associated with them.

Also in this three-part series: At least one photo gallery, two animated illustrations, an interactive graph, several static graphs, and a multi-part video explainer. As Lauren and I explored this series, we both felt that a landing page was absolutely essential. And after a bit of digging, Lauren found that there is, indeed, a landing page for this series! Unfortunately, it’s difficult to find, linked to from only a few of the many pieces. It doesn’t do a great job of introducing the topic or aggregating the pieces. (Part of this is no doubt to blame on the CMS.)

So what could this series look like? Right off the bat, I want to know what Buy Here Pay Here is and why it screws people over, including a flowchart or other visual of how Buy Here Pay Here works. The video Q&A would be a great entry point. This series needs a landing page that shows all of the content items, arranged in a visual hierarchy that makes it clear which give overviews of the general topic and which are associated closely with specific story points. For instance, some pictures in this gallery puts a face on this lawsuit, and this interactive visualizes the data in these documents. However, you can’t get from one to the other very easily.


When Lauren and I first started looking at this package, we thought the documents were all there were. We were incredibly confused until we noticed the little “Read the full series” link.

As a good TribApps nerd, I gotta love and support the idea that you should SHOW YOUR WORK! But we sometimes forget a corollary that’s just as important: EXPLAIN YOUR WORK. I might get lynched for suggesting that putting source documents online isn’t always necessary, but…I don’t think it’s always necessary. I think you need a compelling “why.” In this case I feel like seeing the entire document is actually distracting from the story. I’m not going to comb through all of the documents myself (though some may). I’d rather see the story and explanation take center stage, with just a snippet of the document visible as a secondary element. I’d like links to related content at relevant points in the docs. (Note that the story does link to specific items in the docs throughout the text. Yes!) Ken mentioned in his presentation that he’d originally had much more in-depth explanations accompanying the source documents. I wish those had made it through to the finished version. The data can only speak so much for itself, especially in highly personalized instances like this (as opposed to, say, a table of high-rise fire safety inspections in which you can look up your own building).


The interactive timeline has A LOT of numbers, and it’s easy to lose track of which one means which thing. This would be a lot more compelling and clear with a line chart showing the trend of each number instead, with details available upon hover. Also, colors should mean something. If you’re only using color for differentiation, just put the data in a table and zebra stripe that sucker.

The animations would be better as either static comics (which would probably see some decent social media sharing action) or as an animation, but the hybrid isn’t as compelling as it could be. People like to know where in the narrative they are. (One of many issues I have with pagination of stories.) The nonlinear movement is confusing, and trying to read words as they appear on screen can be stressful for viewers. Words moving onscreen also detract from parsing the visual. Photogs have this down: Powerful imagery + static, concise caption = compelling story. It’s all about the package.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.