API development sheds light on a new workflow
Making a stand-alone scraper and XML readers seems to be the vogue nowadays. I met news API developer for The New York Times Derek Willis last week, and he brought up the good point that many online developers working in journalism had to use APIs and other querying services for their own publications because they are usually not given admin access to the publication’s electronic database.
Like Derek, I want to help journalists solve redundancies within their information gathering and distribution models. All of the hard data that many of my hard-working colleagues gather (i.e. names, ages, dates, etc.) should be stored at the most granular level within a relational or hierarchical database should be easily reused and accessible to everyone, not just journalists. Practical sorting of individual articles, i.e. by relevance, relies on an article’s meta-data, the most accurate of which is derived from the article’s most minor elements.
While I can understand why the publication does not give its own developers access to their information-rich database, I think this resistance to share access to information is symptomatic of the deep separations that still plague the news industry. In particular, a wall has been erected that should not be there: the wall between the IT and the editorial departments. IT people are almost always overloaded with work already. One IT employee often has to maintain intra-office networks, develop web sites, maintain different CMS applications, which are most likely tweaked from a mainstream solution or made entirely from scratch for the publication and parent company, if one exists.
This tendency to bundle positions and overload technology workers has extended to online journalists, who now increasingly take on multiple positions such as web developers, designers, videographers, et. al. along with their editorial responsibilities. As a result, the average new media department’s workflow alienates journalists from their editorial duties, as well as the publication editorial department from the publication’s online products. In order to establish a viable model for web content creation, publications have to restructure their workflow in a fundamental way.
To maintain a good quality site, publications cannot be afraid to experiment in a range of different areas. Journalistic publications must not only staff these positions with reasonable expectations from each employee, but they must give these employees enough latitude to experiment in new projects and find out what old and new techniques thrive online, thus also allowing them to ditch whatever doesn’t work before it becomes a massive drain on time and money.
This level of autonomy is akin to the one necessitated by reporters and editors. Perhaps more than most other professions, journalists rely on a careful system of trial and error, one in which problems must get corrected as soon as they come up so that the next day’s/week’s/month’s/quarter’s product is better. This facet of journalism makes it a natural fit with how development and information sharing works in the World Wide Web.
Large media companies such as NYT and LATimes can afford to invest a lot of research and development without having to commit the entire publication’s to a new media, at least not as much as small- or mid-sized publications. But a large company cannot change at a fast enough rate to address the changing needs of its audience. And I don’t think such a company should be expected to remake itself every few months or years. What a publication needs is a new media department structure that is flexible enough to allow online journalists, developers and designers to have the level of autonomy print journalists have. A publication must allow all of its individual employees to take risks and fail so they can sometimes succeed.