The articles all attempt update the newsroom ethnographies of the late 1970s and 80s — when several sociologists studied how journalists’ working practices influence how the narrative of news is constructed — to account for online publishing.

Domingo’s own contribution to the book is the most striking. Studying four online newsrooms in Catalonia, he noted that online journalists are idealists about their medium: They subscribe to “utopias”— an understanding of what is possible, at least theoretically, in digital journalism.
At the coalface, however, newsroom working practices or technologies inevitably get in the way of these digital utopia.

The journalists he studied, Domingo notes, “felt the need to justify the technological choices that did not fit the ideal model by blaming the limitations imposed by the social, economic and technological context of their media company.”

It makes for somewhat depressing reading, but Domingo’s examples sound awfully familiar. Far from the ideal of using web forums as sources or as a way to interact with readers, for example, they were dealt with in the context of some routinised comment moderation system. Long-planned special events (like elections or Olympics, say) were often the only time that significant storytelling innovations could be attempted.

But best of all, Domingo also addressed the elephant in the newsroom, the content management system:

“The material context of the journalistic work was the result of many technical design decisions that clearly affected the performance of reporters. … Reporters usually did not have the chance to participate in technological decisions and one of the strongest internal social conflicts in the newsrooms arose because of the frustrations with the technical features of the tools they used … CMS design did not always fit the needs of journalists, and discouraged them from routines that would have sufficed in other material conditions.

In other cases, they complained that technical routines were too cumbersome and time consuming, working against their wish for immediacy. This led to a relationship of distrust between the journalists and the CMS staff.

… The technical staffs were too small to deal with long-term development and, short-term problem solving and coding specific solutions for special feature articles with the timing that journalists would like.

Technically skilled journalists in the team (at the side of the online newsroom or the technical staff) were crucial in all the cases, to communicate journalistic needs to the programmers.

…[T]echnical tools evolved quite slowly in the eyes of the journalist. CMS always had noncritial bugs that took months to be solved, in the queue for the next version. They made journalists’ life less easy, but they developed routines to deal with the bugs …

…Even though online reporters did not usually participate in future project designs, they indirectly participated in innovation processes by accepting, rejecting, reinventing or adopting new technical tools or work routines.

The article is essential reading for any newsroom manager. A CMS with poor backend usability will engender bad practices as journalists cut corners while striving for immediacy or some other ideal. The same is true of a brilliant CMS delivered with badly-executed templates that journalists can’t fix.

Never mind the cool stuff we’d all like to be trying — if the CMS makes it difficult (or is designed to discourage) the basic things we ought to be doing — like creating inline links in stories — time-pressed journalists simply won’t do it. In other words, the technology begins to determine content.

Worse, I suspect badly-designed CMS backends engender resistance to the online medium among print journalists by leading them to assume that all this digital stuff must be frightfully complicated.

Gripes about the clunkiness of content management systems are almost universal among online journalists. At one conference I attended a few months ago, several editors compared how long it took to post just one simple story to their websites. One had counted 62 clicks to complete this most basic publishing process. Another recounted how journalists were exporting image files out of one part of a CMS, e-mailing it across the newsroom for a colleague to use on another part of the same CMS because they knew of no way of moving files within the CMS.

Everyone who works on a news website seems to have a horror story like this. Some have happy endings involving ingenious, creative workarounds that saved the day. But most just end in head-shaking, eye-rolling and curses.

Everyone who has worked in a publishing company bigger than their spare bedroom understands there are plenty of good reasons to have a “heavyweight” CMS in the context of a large publishing company.

That’s hardly a consolation to reporters trying to break a story online with the sort of immediacy or interactivity they know to be (theoretically) possible, or to online editors eager to replicate the sophisticated new semantic tagging or SEO capabilities that a couple of plugins just gave to their personal blogs.

Everyone who has used blogging tools understands how simple and extendable the backend of a web publishing system can be. And a journalist frustrated by the discovery that expensive newsroom CMSs can’t do the same things they can easily achieve on a simple blog is experiencing what Domingo described: the frustration of discovering the difference between digital utopias and digital reality.

Is anybody out there actually working with a system that behaves? Let us know in the comments what it’s called.

On Twitter the other day, Patrick Beeson nominated Ellington, the Django-based system developed for the Lawrence Journal-World. Any other candidates?

One interesting thing about the Advertiser’s project is that the slideshows are actually hosted off-site on the blog of Advertiser Picture Editor and Chief Photographer, David Berman.

Andy thinks this was a good idea for getting around the limitations imposed by the creaking content management systems many news web sites use.

“I’ve never understood why, given the restrictions of the centralised templating systems the locals are labouring under, more and more outfits don’t go to free or low cost services outside,” writes Dickinson.

Berman himself pipes up in the comments: “It wasn’t hard to decide to go our own way to get the IT soloution. It just would have taken more time than I could allow.”

I know what they mean. This week, I’ve been getting reacquainted to toiling within the limitations of a “content management system”, which will henceforth be known as a “restrictive centralised templating system”, or RCTS. Arrgh.

We’re looking to make some major upgrades to our RCTS, and on thing I am trying to insist upon is a simple Unix box to host blogs and other rapid-development experimental projects. Why wait for external web developers to do things you can do much faster in-house?