So, I gather that in newsrooms it’s become [fashionable](http://dunes.cincinnati.com/data/) to [put](http://www2.tbo.com/static/news-special-reports-data-bay/tbo-special-reports-database-main-page/) [public](http://www.indystar.com/apps/pbcs.dll/section?Category=LOCAL08) [records](http://www.azcentral.com/datacenter/) [online](http://www.app.com/apps/pbcs.dll/section?Category=data).
> But if you take a step into one of the databases and you get to my second problem with them: couple of search boxes and a button.
> Is that really it? Is that the big newspaper.com push into data? Sprawling, barely organized pages to get to a couple of search boxes and a button?
I’ve certainly been [guilty of this](http://projects.ajc.com/purchases/) myself.
The best part is that [Zellyn](http://zellyn.com/) made it so that journalists, developers, designers, or anyone in our group can create new lists on the fly in our neat-o keen [Django](http://www.djangoproject.com) application.
It’s the first time at work that we’ve built a tool around a set of data. Normally we lump our work into two camps:
* **Data-driven applications** like my purchase card project expect that the only human interaction is our loyal readers contrasted with…
* **Tools** like our gallery publishing system expect staff users on the ‘backend’ *and* loyal readers to interact with them on the ‘front’ end
This the first time that we’ve merged aspects of both and I think it provides some urban renewal to what could otherwise be a [data ghetto](http://www.mattwaite.com/2008/01/02/data-ghetto/).