The convergence of media has given rise to some strange bedfellows. Once upon a time a news room was filled with copy editors, journalists, photographers, phones blaring, and daily deadlines. Now it’s more common to see plasma screens, banks of computers, a multimedia department and us – the proud web developers.
A good working relationship between developers and the “journos” takes some time to forge: it depends on the environment and the willingness of both parties to accept and comprehend each others’ roles. But because these roles are so different, misunderstandings are inevitable. In some places, I’ve noticed a level of antagonism arise between the two groups where each regard the other as an ignorant impediment to their own jobs.
Developers take great pains to craft and maintain clean and compliant code and become disillusioned with the editors’ constant and successful attempts to break it. They can’t fathom how an editor would input 100 break tags to clear an image and consider a little piece of coding knowledge in an eager writer to be a dangerous thing. To a developer, an editor is someone whose basic role is akin to data entry. It is inconceivable that they should require any other skill beyond copy and paste and more HTML tags than <h2> and <p>.
Editors on the other hand, think that developers are a team of geeks who, because they don’t want to do any work, enforce draconian rules on the publishing process and stifle any attempt at creativity. Editors feel that developers don’t understand a thing about the craft of news writing and the importance of timely and topical messages. The attitude is that they use acronyms to confuse and hide behind their inability to deliver what an editor wants.
Wording, coding and loading
Fortunately, I’ve been in both chairs. As a writer hacking away at a desktop word processor composing articles destined for the web, I was on intimate terms with the way text had to be “cleaned and gleaned” before it was suitable to be published as HTML. Any variations on the template (usually defined by designers) had to be fudged or “requested” meaning that a designer had to create them and a client side developer had to provide the code. In a news environment, more so in an online environment where we can break and update stories when and from where we please, this is a huge frustration.
So too having worked with editors and journalists across many industries in a development capacity, I have heard their frustrations in relation to technology: “Why should we have to learn HTML and CSS? Don’t we employ people to take care of that for us?”
My answer was always that they should learn simple HTML and perhaps a little CSS, or at least what it’s used for, and that I would offer to teach them what they needed to know. Some accepted and others spurned the offer as if I’d just invited them to watch moss grow on roof tiles. But I understood their complaints. Arguably, more than in any other sector, the media and entertainment industries are experiencing profound changes due to the rise and rise of the internet. Concurrently, all the platforms, a great deal of the content, the language and yes, even the roles are changing with it.
In today’s web-focused newsrooms the journalist is expected to not only produce the content but to publish it at well using whatever tool is provided for them. They’ve been employed to write, edit, research and provide the content that keeps people coming to the site. But the variable output of content management systems and the strict rules that are required to maintain a website that validates, create a digital minefield. Training and documentation might be non-existent, technology changes but the pressures to submit their copy in a presentable format remain the same. For example, if a means to create a breakout quote is not available to the editor, who has to immediately push out a breaking story, they will improvise and we, the support staff who look after the integrity of the site, may come across something like this:
<font size="3" color="red">
"And a minister said something interesting."<br>
<i>The Hon Henry Honeybun</i>
The writers don’t care. Their material is out and they’ve done their job. Any self-respecting web developer however is prone to suffer a mild spasm. Larger organisations that can afford to hire technical support staff who can respond to these events straight away have mitigating buffers. But the night desks and smaller news teams will publish what they can get away with, despite breaking the layout or every rule in the HTML validator.
It might be a gratuitously evident comment, but people publishing content to the web – whatever that content may be – should have the tools and knowledge available to them to do so. Saying I work as a writer shouldn’t negate the necessity for me to understand the medium in which I publish. I should know what I can and can’t do and follow the advice of the developers.
But, it goes both ways.
If I am a developer (responsible for the frontend of a news website), it’s important for me to know how a newsroom works and to understand the role of journalists in newsmaking; it’s also worthy to discover the mental process by which people in my team will be publishing to the site, not just the physical workflow. For example, how and when does sub-editing take place? Who approves the final draft? What elements of a story should be semantically marked up? And so on. When armed with this knowledge, I’ll be able to better support them so that they can do their jobs properly. Providing the right tools is only a part of this. Attaching a digital style guide to the formal style guide is one option. Proper training is another.
Despite the gaps in the knowledge of both parties, I think we are at the tail-end of the transition and that we will see a new generation of journalists who will have had training in web publishing. Accordingly I hope that we’ll see a new breed of developers, particularly bloggers, who appreciate the art of the word and the importance of a journalist’s and editor’s role in the creation of news. Ultimately we’re both producing lines to achieve the same end: whether they’re words or code, our medium is online and our audiences shouldn’t have to know that there’s a difference between the two.