I've had a few interesting conversations this week about quality control in newsrooms, in part sparked by the diagram I posted last week showing how many pairs of hands various kinds of news stories go through before being published.
One thing that came up was how irritated people are by the number of typos regularly seen on news websites - including nzherald.co.nz and stuff.co.nz. As Nathan said in a recent comment, "I generally expect better of professionals."
I haven't worked at either of those sites so I can't speak for what goes on there. But in my experience the problem is twofold: inadequate systems (Content Management Systems (CMSs) that require users to undertake multiple steps for simple tasks - increasing the likelihood of mistakes); and poor workflows that were designed decades ago for print and haven't been revised to account for the website.
Some typos simply come from typing too fast - you'll find plenty of these in blogs and comments (including mine) where people type quickly and give only a cursory check before hitting 'send'.
More prevalent in news publishing are cut and paste errors - where a sentence has been edited or moved and during the process a word/punctuation mark/sentence has been inadvertently cut out, cut in half, transposed or reconstituted without due care for syntax or grammar. (That's why you see double words in text and missing full-stops).
How does it happen? Easy. Take a breaking news story. They're often bits of wire stories spliced together with a few paragraphs filed by an inhouse reporter. Very often those paragraphs will have been filed by email and copied and pasted into the web CMS. Just as often, the wire story will have been copied and pasted into the web CMS.
Take all that copying and pasting and re-working of sentences, throw in some time pressure and you've got mistakes waiting to happen. Speed is of the essence so the story goes live without anyone else reading it. Even with less urgent stories there's often only one duty web editor anyway, so there's no one else around to have a look at it before it goes online.
So why doesn't someone read it after it's gone live? Good question. Some structured peer review could go a long way here. And as I keep saying, readers would gladly help if you made it easy for them.
Most stories, though, are prepared for the newspaper first before finally being loaded online late at night by a tired person. On the way, they'll go through nine or more pairs of hands, typically, and two CMSs.
Most likely both CMSs will make hard work of cutting, pasting, categorising and styling text - increasing the likelihood of mistakes being made along the way. Cyber, a system widely used for print in NZ, would fall into this category I suspect, based on my brief encounter with it. If you have a different view, I'd love to hear from you.
What's the answer? One, news organisations need better CMSs which have been designed for neutral input and multi-platform output - no more cutting and pasting, easier editing and mark-up, and the fewer steps the better.
Two, they need to take a critical look at their workflows and redistribute resources: essentially take a couple of those people in the right-hand columns and move them to the left.
Sunday, March 30, 2008
Mistakes are built into the system
Posted by
Julie Starr
at
1:50 PM
2
comments
((•)) Hear this post
Tuesday, March 25, 2008
There's something wrong with this picture
On a similar tack to yesterday's post about when a story is 'finished' enough to go online, I was reminded while planning a sub-editing lecture recently of how lopsided today's newsrooms are when it comes to handling stories for web and print.
The image below is a rough snapshot of how many pairs of hands various kinds of stories might pass through in your average newsroom - from reporter through chief reporter, news editor, web editor, chief sub-editor, page layout, sub-editor, check sub, proofreader, editor, edition controller and so on.
From left to right:Audio/video
Breaking news for the web
Web-only stories
Newspaper stories
Web shovelware
(where stories are readied for the paper and subsequently posted online at the end of the print day).
Hard to imagine anyone allocating resources like that if they were designing a newsroom today, isn't it.
On the upside: there's lots of pairs of eyes on those newspaper and shovelware stories to catch mistakes before they're published.
On the downside: there's lots of pairs of hands on those newspaper and shovelware stories to introduce mistakes before they're published.
Not to mention the extraordinary length of time it takes to get a story online using the shovelware method.
Time for a rethink, surely. A rethink, a critical analysis of newsroom processes, a redesign, re-training and roll-out.
Posted by
Julie Starr
at
11:16 PM
2
comments
((•)) Hear this post
Wednesday, February 13, 2008
Wellington turns on the charm
Not only has the sun shone all day, but I've met more interesting people in the last 24 hours in Wellington than I have in the last couple of months (I should probably get out more).
As if by magic, before I'd even found my hotel last night I'd run into (almost literally, with my wheelie bag) a guy who specialises in business processes and is a fan of EPC (Event Driven Process Chains - used for mapping processes and workflows). That may not sound like much to you, but it brings the total number of people I know who use EPC to four. Me, a couple of colleagues in the UK, and this guy. Mapping workflows is not, as you can imagine, everyone's cup of tea. So the chance to sit down with someone and yap about it for a couple of hours was truly an unexpected pleasure. (My interest in EPC, by the way, arose when we used it for some web-print integration work at the Telegraph).
And I got to talk workflow again today. First, during a guided tour of Radio NZ with webmaster Richard Hulse, who impressed hugely with all-round affability and a pragmatic and user-friendly approach to systems development. Then with some people I met at the Dominion-Post who gave me an equally enjoyable look around there.
Next up is the Webstock conference, so it just gets better. Tomorrow's line-up includes Nat Torkington, Peter Morville, Michael Lopp, Sam Morgan and Jill Whalen. Can't wait. I'm toying with the idea of using CoveritLive to post from the conference; will see how things look tomorrow.
And all this workflow and webhead fun is set against the backdrop of rediscovering a really accessible city. I hadn't been to Wellington for more than a decade and had forgotten how user-friendly it is. When you're in the city, you can walk pretty much everywhere you'd care to go, and generally within 5 or 10 minutes. (In Auckland you have to budget 45 minutes to get anywhere). The waterfront is close and works for pedestrians, the train station's close and there's no shortage of eateries and drinkeries. Nice.
Posted by
Julie Starr
at
7:28 PM
3
comments
((•)) Hear this post
Labels: EPC, webstock, wellington, workflow
