* Note: This post came from a version of this blog that got lost in a server failure. It's been restored from old RSS feeds, Google caches and other sources. As such, the comments, links and associated media have been lost.
The other component of the data ghetto that bothers me is that you can’t find that data outside the ghetto. Please, someone point me to a place where there’s dynamic content being fed to the story level pages. I have yet to see where someone’s crime data is being fed into a story about a crime, i.e. a map of murders from the data ghetto’s crime application dynamically generated on a story page about a murder. Or a list of the largest donors to a politician from a campaign finance app on a story about a politician.
And that seems to be a problem we’re creating for ourselves — we’re only thinking about getting the data online, not about what to do next. Or about what else could we do with our data. Or what could someone else do with it if we let them. We’re content with a couple of search boxes, a button and a results page. And we’re content to leave it right where we put it.
Doing all this got me thinking of another concept: molten content.
I’ve always thought of the work I was doing as building something out of raw materials. As a reporter, I did interviews, read documents and analyzed data. All that raw material was worked into a story, a graphic, maybe some photos, and lately some online interactive content. Building news applications, I’m finding, is more like working with metal. The more malleable you make your content, the easier it is to mold your application into all the different places it may need to go.
Most places, the data in the main newspaper.com CMS is cold iron — hard as hell to work with, if not impossible. So most of the time, we’re not going to be bringing our newspaper content to our applications. But what if we brought our application to our newspaper content?
Ask yourself this: Why can’t you find data from a newspaper.com’s data ghetto outside of there? A large reason for a lot of data ghettos is that the CMS is on one set of servers based on one technology and the place for data is on a whole other server setup with another technology. That’s driven by the horror stories most newspaper.com webworkers have about how gawdawful their CMS is and how the CMS won’t serve up this or handle that (or hell, even shovel the previous day’s paper online cleanly).
But, if you designed your application right, your CMS problems are an excuse, not a reason.
As I go forward, I’m adding a hidden requirement to my applications: make the data molten — the stage where the metal is nearly liquid, easy to pour in whatever form I need it to go into.
Here’s a simple example: PolitiFact’s widget. It was my first attempt at molten content. I’m going to breeze over the code for now — if anyone wants me to detail it, post a comment below and I’ll do it in another post.
Here’s what I mean by molten content. PolitiFact resides on a server at my employer’s server room. This blog is hosted somewhere else. That’s Django, this is Wordpress (which is PHP based)(* this is a post from my old blog. It's all Django now). Different systems, different servers, different states, different everything. And, here’s that dynamic content:
So, if I can take PolitiFact and put it on my blog with these tools, why can’t we take it a step further and put any and all data from our news applications into our story pages?
Because, as I just showed you, we can. We can do it better than this. If you’re developing news apps and don’t know anything about web services, you should start learning.
The broader point here, divorced from technologies and implementations, is that we need to start thinking about where our data is going to go and what we’re going to do with it beyond search and results pages at our one URL. More on this in the coming months, when some other projects I’m working on go live.