I recently followed a Twitter link (and I’m sorry, but I can’t remember the source) to a video made by the CoPress group about creating “the web-centric newsroom”:

The Web-centric newsroom from CoPress on Vimeo.

Point one is elementary: of course people search the web for story ideas. Point two, to post online fast to compete: well, that’s a fine and good idea. But point three- web-first workflow, is the main focus of the video, and it encourages us to post online first and move that content to print.

This is all well and good as a theory, but there’s some serious problems for most of us in implementing any real kind of web-to-print workflow. Let’s take a look at the problems with this kind of approach.

Get staff to write material on the web

This has got a couple of issues. Firstly, the investment of time and energy training a staff to use the content management system as thier main composing tool. Sure, my staff are smart, and they could get to grips with it: but using a HTML-based system first and foremost? The spell checking system on web browsers and CMD systems simply isn’t good enough for the levels of accuracy required by a professional publication. Worse still, many individuals would rely on their web browser’s dictionary without a second thought, which would almost certainly introduce “corrections” of of proper English in favour of Americanisms. Further, in my opinion, asking a writer to use a proprietary tool for a single purpose will lead to quicker fatigue and boredom. And it would be for the sole purpose of working for the paper: no-one is realistically going to use a CMS (let alone the specific choice of CMS your paper uses) for their essays and class assignments.

But perhaps the section editor could simply place the content on the CMS after they’ve received it from the writers?

The problem with editing online

Quite apart from the spell-check issues, the fact is that text on a screen is tremendously hard to read. I do as much copy editing as possible from print-outs. But were I constrained to the format of a CMS screen, the job would become even harder. This is simply due to the way a CMS backend is designed: the text area is uncomfortably narrow to allow for further web-based controls, on top of which there are graphical elements and negative space. Take, for example, this rather wide version of the Wordpress backend.

This is clearly not a comfortable environment for anyone to analyse a text for flaws, errors, or potentially libellous phrases. Now, the latter happen rarely, but it’s important- and more important still is the everyday quality control problem caused by an environment simply not designed for the purpose we’re talking about here.

Design issues

This, for me, is the deal-breaker. I’m not a new media sceptic. I love the possibilities. But the college newspaper environment can’t be compared to the problematic realm of regional or global news organisations. Our format is part of the reason we enjoy continued existence: we’re read because we’re picked up on the way to lectures, in the coffee shop or canteen, or around the student society areas. We’re not really trying to move to the web, because to do so entirely would probably kill us. No, we’re a newspaper. Hopefully, a well-designed, accessible, visually attractive newspaper.

The issue with taking content from an online system is that it doesn’t have constraints on design that are comparable to the print format. Web design isn’t easy: but it’s about grids, transparency, using the available code tot he maximum, etc. An article can be an unlimited length in most web designs: in print, it has to be very specific length in physical space. For example, let’s say we agree a word count of 700 words. On the web, that’s fine. In print, our copy editors might be left with this:

Which is, if you can spot that helpful InDesign red plus in the corner, running over. Our intrepid team of copy editors, however, would spot this, and they would closely look at the piece to remove superfluous words or paragraph breaks to make the content fit.

This is because 700 words doesn’t occupy the same physical space all the time. Granted, the example above differs by one word, but you get the idea. I’ve seen some long pieces differ by 100 words or more moving from one set of type to another. Print content can be be placed online without alteration. It doesn’t work the other way around. Thus, in the end, we have two options:

1. We can have content in which the supposedly same piece differs online and in print.

2. We can re-update our content after print design to ensure both pieces are identical.

For me personally, the former isn’t’ acceptable. It introduces a lack of consistency which is both amateur and confusing- particularly when one considers their online presence as an archive, howver temporary, of their primary product. The latter is a print-to-web workflow: a wolf in sheep’s clothing. We’ve taken our print content and moved it online, and the copy-and-paste approach we’re probably going to take to this means we’re unlikely to save any time by placing a close imitation of final content online first.

I’m up for trying it out some time later in the year when everything’s ticking over by building a single page or section this way. But, unless someone has suggestions on how to improve the issues I’m talking about above, such a move might be done for mere curiosity rather than any hope that it might speed up the newsroom workflow.

Posted by Dave Molloy in •Journalism •Tech

Comments:

Add a Comment: