More on Frameworks for Reporting: Lessons from PolitiFact

Posted Monday, August 3, 2009 at 1:31 a.m. by Chris Amico in Frameworks for Reporting and Lessons From... about Barack Obama, Django, frameworks for reporting, journalism and politics

My last post on frameworks for reporting covered Patchwork Nation, my first big project for the NewsHour. What really got me thinking about this, though, was PolitiFact's Obameter.

The Obameter launched in January as part of the St. Petersburg Times' PolitiFact project (winner of a much-deserved Pulitzer prize). It keeps tabs on 500-plus promises made by then-Senator Barack Obama as he campaigned for president over the last two years.

Actually, I should rephrase that: The application doesn't track anything. It provides a structure for reporters to keep tabs on what Obama promised during the 2008 election. And that's really the key thing that defines a framework for reporting. Reporters and researchers and editors are still the main drivers of the story.

Here's how Matt Waite, who built it, explains the relationship between the Obameter's technology and its journalism:

PolitiFact may not look like traditional journalism, but it very much is. It's a story type that's been around for decades, a type of accountability journalism that's been around much longer than that. The difference is that we aren't just creating a field for a headline and a field for a story and calling it quits. The difference is that we view content as data and the database as an act of journalism in itself. Each promise in the database is a piece of journalism and a piece of data. And all the acts of journalism that combine to make up the database form one meta act of journalism. But without using data as an organizing principle, most of what makes PolitiFact more than just a collection of stories would be impossible.

(from Matt's post Data = Content: Content = Data)

What hooked me with the Obameter is the potentially monstrous task of collecting, organizing and tracking 517 promises. As I noted in a comment on Matt's post (the one quoted above), following campaign promises that may or may not be fulfilled over four years is difficult for two reasons:

  1. There are a lot of things to keep track of, and
  2. There's rarely a schedule for when they'll get done.

On the technical end, Matt said (in a reply to my comment) the Obameter handles this with two fields on each promise model: a notes field, and a date to next check up on the promise's progress. On the editorial side, reporters divided up promises and cover them much like a traditional beat.

I've done a lot of beat reporting. As Matt said above, without any organizing principal and an understanding that stories are structured data, each report sits by itself with no context except what can be crammed into boilerplates.

When the database is the story, we don't have to start over every time. Readers can dive in, catch up and go as deep as they want.

More examples:

  • The Los Angeles Times: Mapping LA: The LA Times set out to create a comprehensive picture of the city, which is harder than it might sound if you've never spent time in LA. Reader comments helped reporters redraw neighborhood boundaries and provide a clearer sense of what it's like to live in the city's many enclaves.
  • The New York Times: Living with Less: The NY Times provides a space for people to talk about how the recession is affecting them, with lots of ways to participate. Each piece adds to a much deeper story about today's economy.

What else is out there?


aug 3, 2009 at 5:46 p.m. // Daniel said:

Really smart thoughts, Chris. I appreciate you taking the time to write them up (I just read this and the previous post in consecutive order).

A few things I'd like to add. First, I think one critical component to success of any idea like this is if you can get the reporters to adopt it as a part of their workflow. The way that I interpret the concept of a framework for reporting is that it's really just a structured database for all of the activity a reporter might participate in as a part of their research, writing, and production process.

For instance, with the Obameter, the reporter gets the notification that they have to check up on a campaign promise. They do a bit of sleuthing and, say, come up with two articles and a phone interview to prove that Obama fell through on the promise. When they report back to Obameter, there are fields for the reporter to drop in the URLs of the articles and phone interview which become their supporting documents. In addition, they can write a post which serves as the explanation for why the promise was marked as failed.

In some senses, a framework for reporting (or at least my interpretation of it) is one part tool for organizing the reporting process and one part tool for presenting the information to the public.

Another critical part, I would think, is how the information is stored and what information is structured. As a part of developing the framework concept, I think it'd be important to establish strategies to address this.

aug 3, 2009 at 9:01 p.m. // Chris Amico said:


That's it exactly. It's about building tools that make managing all of that easier, but I don't think any of it is possibly without buy-in from reporters and editors.

PolitiFact, obviously, has buy-in in spades. Patchwork Nation was running for a year before I joined the project (my job was to rebuild it and push it farther). I haven't had to start something like this from scratch, yet, but I expect it'll be harder.

As for workflow, Patchwork's involves a lot of emailing and hunting for data and playing with maps until we find a story. We can do a lot of that because making maps isn't hard, we have an idea of what we're looking for and we know what to do with it when we find it.

Comments are closed for this post. If you still have something to say, please email me.