Separation of powers
OK, this post is a little off-the-beaten-path of my main argument, but it’s somewhat relevant. Over the past several years, parallel trends led the evolution of Web design and Web development, and I wonder if there’s a parable in here for journalism.
If you were a Web designer in 2000, the ultimate product of your work was typically an HTML document. Unfortunately, HTML wasn’t built to handle design, so sophisticated looks were only possible with a fairly cumbersome amount of hackery. Imagine trying to lay out a Web page in Excel. (I’m really not exaggerating.) Designers had to slice up images to fit precisely into a matrix of table cells. Every element on the page — each headline, each paragraph, each image — was wrapped in code specifying where it should go and what it should look like. Changing the look of a bunch of Web pages meant wading into each and every page and carefully altering the code.
Right around that time, some forward-thinking designers began a push to separate the design of a Web page from its content. With the popular adoption of CSS, designers were freed from spreadsheet layouts, and they could set flexible but universal rules for how page elements should be displayed. They could easily set paragraphs in the body of an article to look one way and paragraphs in the article’s sidebar to look another. And best of all, this could all be done in a single stylesheet document which was completely separate from any content. Altering the look of all your pages meant simply altering a rule in the stylesheet.
Meanwhile, a Web developer in 2000 was probably using the coding language PHP. The defining advantage of this language was that its code could be deposited right into an HTML document, allowing developers to write mini-applications in the middle of a Web page … instant gratification. And many did. But it often had the consequence of tying code and content together, which got messy real quick. This and other aspects of the language did little to encourage coding discipline, and Web applications from the era were often slapdash concoctions that scaled poorly and inhibited collaboration.
In recent years, developers have followed designers en masse in seeking to isolate the different elements of a Web application. The database schema was neatly defined in one realm, the functions that interacted with the database were segregated in another, and the templates that called those functions had their own place as well. Although the same developers often still work in all three realms, they’re increasingly turning to frameworks like Django and Ruby on Rails to help enforce that separation of tasks.
Your typical act of journalism today comprises at least three fairly discrete functions. We first (1) gather, then (2) filter, and finally (3) present information. Might we be able to build a case for giving each of those functions its due?
What if each news site had a repository where we attempt to publicly store most of the data we collect — interview recordings/transcripts, FOIA-ed documents, databases, raw video, etc.? And what if we also provided a sandbox where our users could annotate those transcripts, highlight documents, point out patterns in the data? And then finally, give them a platform on which to present their findings, encouraging them to tell creative and engaging stories?
Of course, the stuff of our trade — truth and information — is messier than code and even design. I doubt journalism will ever be orderly, and some of the best stuff is the product of no discernible process or discipline. But I think there are respects in which our tendency to see the act of journalism as a sort of undifferentiated muddle might hamper our creativity about what journalism can be.
No related posts.

[...] interested in being somewhat methodical about this. Again, journalism isn’t science. But an effort to quantify what we might be missing (or in danger of missing) could help us focus [...]
In search of great questions at Newsless.org
12 Dec 08 at 9:13 pm