26 min

The Media and Their CMS Apps

https://medium.com/@jotham.sederstrom/regarding-shaun-king-and-the-daily-news-e458523367ce

http://nymag.com/following/2016/04/dont-trust-your-cms.html

I think this says more about the poorly-designed workflow systems in some media orgs, and how the media loves to whine and make excuses for their foul-ups. What about attention to detail?

If journalists are forced to use a wretched CMS or workflow system, then it's still at least the media org's fault. Maybe the journalists should revolt against their internal system and demand better "working conditions."

The workflow steps outlined in a couple articles are amazingly bad and dumb for 2015-2016. It sounds like they are 20 years behind. A self-hosted Ghost blog app might be a huge improvement.


From the medium.com post, written by the editor who was fired by the Daily News.

So it was with no small amount of shock that I learned on Tuesday the Daily Beast had leveled serious plagiarism accusations at Shaun regarding an exclusive story its reporter had published earlier that morning. Within a matter of hours after Shaun published his own column about Elliott Williams, a victim of neglect inside a Tulsa County jail, a large block of text — sans quotation marks or attribution — was discovered by the Daily Beast to be identical to two paragraphs from their own story. Rapidly, other news outlets pinpointed another example where blocks of text appeared identical to another report, again without quotation marks or citation

This was my fault and I accept 100% of the blame.

Correct. But ...

In all honesty, the controversy — a fuck up on my part, to put it bluntly — comes down to two unintentional, albeit inexcusable, instances of sloppy editing on my part and a formatting glitch that until Tuesday I had no idea was systematically stripping out large blocks of indented quotations each time I moved Shaun’s copy from an email to The News’ own Content Management System, or “CMS” as it’s called in media parlance.

First, the workflow problem:

_"... moved Shaun’s copy from an email to The News’ own Content Management System ..."

It appears that their CMS is so bad, that they don't use it until near the end of the writing/editing process.? I wonder how much they paid for the CMS. Copying and pasting from an email in 2016!?

Did the app remove the indented spacing or the actual quotation marks or both? I can see an app removing spacing at the start and end of lines or copy.

The writers should use some kind of start and end text characters to indicate block text, such as Markdown's greater-than sign. Or place a bunch of hyphens or equal signs at the start and end of the block text.

But how did this go unnoticed AFTER it was published or doing the proofreading process? Does the CMS offer a preview mode for writers and editors to use before giving the greenlight to publish to the world?

It doesn't make sense that neither the writer nor the editor took the time to verify that what would be displayed on the website matches what was originally written.

Maybe the CMS acted squirrelly. It definitely sounds like the CMS does not offer a good writing environment, which is probably another reason why some smaller publishers will switch to using Medium.com.

But humans are responsible for final approval before publishing. Blaming the CMS or blaming a busy schedule are horrible excuses. Maybe this is one reason why the public has little trust for the media.

Expanding on the excuses:

In those two cases where no citation or hyperlink appeared in the column, I believe I likely cut attribution from the top of Shaun’s quoted text with the intention of pasting them back inside the block — *only to get distracted with another of the many responsibilities I juggled as an editor.*

I assume that one of the responsibilities of an editor is for the story to be accurate.

This supports my belief that multitasking is a good way to complete many tasks with mediocrity.

On any given day I was tasked with editing not only Shaun’s column but roughly 20 other news stories from five reporters, all of whom filed early and often. Add to that a whiplash-inducing crescendo of breaking news, a handful of administrative responsibilities and the chaos typical of most newsrooms, and it’s easier to fathom how frequently focus can snap from one second to the next.

Focus can snap, that's a problem with multitasking. Interruptions. But this sounds like a workflow design problem. And maybe a business problem. Is the focus on quantity over quality?

Anyway, the editor is making excuses.

This is not an excuse, but here I take issue with Jim Rich’s assertion that these mistakes were “inexplicable.” They can happen easily if you’re not paying extreme attention to detail at every moment.

Not paying attention to detail can lead to mistakes?? What a shock.

Attention to detail should be an unwritten description of the editor's role. That was the editor's job. That's why he should have been fired. He failed to fulfill a basic requirement.

But I don't understand how the writer does not have a role in previewing the final version of the article before publication. If the workflow leaves the writer out of the process, then that's the org's fault.

I don't think that the writer should receive any blame, unless the writer was suppose to preview the final version, but someone got lazy.

The editor receives most of the blame. The org's workflow and CMS choice could receive a lot of blame too.

Many of us in the news industry are increasingly under pressure to deliver an ever higher volume of stories with ever fewer resources and let’s just say, that doesn’t help. I don’t say that to absolve myself of blame, but to illustrate how this happened with no intention on my part to damage Shaun’s reputation or the paper’s.

Whining.

Okay, the editor is a victim of the decline of the newspaper industry, thanks to Craigslist, Google, Facebook, and um, heck, the entire web.

Maybe the website can add more JavaScript, trackers, ads, and other bloatware to their articles. That should help.

Finally, I want to personally apologize to Kate Briquelet of the Daily Beast and Rob Arthur and Jeff Asher of FiveThirtyEight.com for removing attribution and links to fantastic stories that Shaun originally cited. I absolutely did not mean to do that, and fundamentally believe that proper citation is crucial to upholding basic journalistic standards and ensuring transparency about the reporting process with readers. I am sorry.

Removing the attribution links is not the fault of the CMS. As the editor noted earlier, he had planned to add the links, but he got busy and distracted. But this occurred more than once. This part of the story seems blurry.

It would be foolish to leave out links and attribution intentionally because the hack would get exposed easily and quickly like what happened. I believe these were unintentional mistakes, but the editor failed to be an editor.

From the nymag.com article:

One of the great promises of digital publishing has always been that it’s easier than old-fashioned printing. No presses needed, no warehouses, no infrastructure, no pesky typographical union: You type into a box, you hit the blue button, and you’ve published.

That's not a promise. That's fact, and it has been exactly that easy for more than 15 years.

It was that easy in 2001 when I started blogging with the Greymatter app that worked with a web browser, producing a static HTML site.

It worked that easily with my first version of ToledoTalk.com code when the site began in January 2003.

Many hosted blogging tools have made it that easy with more sophisticated features available if the writer chooses.

  1. Click the Compose/Post/Write link or button
  2. Enter text in a textarea box (and maybe a title in a separate text input field)
  3. Click "Post" (or create, update, publish. possibly click preview first, but the post can also be edited to correct mistakes.)

Only a few steps are required to publish to the world. And only a small amount of form junk on the post page is required. For my web publishing apps, I have three pieces of form junk: textarea box, preview button, create/update button. A link exists, however, to use the JavaScript editor instead of the HTML textarea box.

That's how easy it is for blog, wiki, and message board software. It can be more complex if desired.

For media orgs where multiple people may touch a piece of writing, more sophisticated software or at least a well-designed workflow is needed.

It's easy for the rest of us to publish to the web. That's probably why Facebook, Twitter, and Instagram are popular.

But maybe it's difficult for media orgs to publish to the web. Again, this is why Medium.com is an interesting business to follow because Medium makes it easy for media orgs to publish to the web.

Back to the article:

Of course “easier” usually just means that the work that used to be done by humans and machinery is now being done on and by computers.

What? Humans are still writing and editing most of the stories, correct?

Publishing to the web is, in many ways, hugely more complicated than publishing on a printing press; ...

Well, that's the dumbest thing that I have read thus far in 2016. Journalists probably do more harm to the news industry than anything else with that type of thinking.

... it’s just that we trust our programs — the text editors we use to write and the content-management systems, or CMSes, we use to publish — to do most of the complicated work.

Okay, but if the CMS caused a problem, then where are the humans to proofread and edit the content?

But as anyone who spends most of their time head-down in a CMS will tell you, CMSes (and text editors, and email clients), are not to be trusted.

More whining and excuses from the media.

Emails furnished by King showed that his original copy (which he filed in the body of his emails — the sound you hear is my teeth grinding just thinking about that) had in fact correctly attributed the quotes ...

Yes, teeth should grind. And how do journalists accept this? Why don't they write an endless array of articles that rail against their writing systems and workflows?

If some journalists like to write stories that influence decisions made by politicians and business, then why don't they do the same for their internal processes? Expose their sausage making flaws.

At least the nymag.com writer acknowledges the human mistakes:

Sederstrom wrote a long, well-articulated apology on Medium, in which he takes full responsibility for the mistake. He also explains how it happened:

This may sound like a paltry excuse: a poor carpenter blaming his tools. And, obviously, Sederstrom and King both should have been checking the final product.

That's it. End of. They should have been checking the final product. Why didn't they? Despite workflow and CMS issues, not checking the final product is the worst flaw of all. It's inexcusable behavior.

But of course, the media likes to blame everything else more.

But it’s also the kind of story that web editors everywhere will recognize immediately. After all: The only indication that King is directly quoting rather than paraphrasing is the indented block quote line. In other words, the line doesn't exist in the text as written. It exists in the text as formatted.

That's a human design flaw. Bad choice. They should have established a style manual for how to markup a story if it will be submitted within the body of an email message, instead of as an attachment from some program. But either way is absurd.

If the CMS is so bad that the writers and editors cannot use it to create their content from the start, then the company should replace the system. I'm stunned that someone would file a story within the body of an email.

But despite all this clumsiness, the writer and editor could have caught the flaws by paying attention to detail and checking the final product. How come this is not being addressed in more detail?

If we all wrote directly inside the content-management systems where we publish our work to the world, this would be less of a problem. But very few of us do (for one thing, they generally don’t save your work).

What? What in the hell does the writer mean that the CMS does not save work? I'm writing this post within "my" JavaScript editor. I have not hit the save button yet. Every five minutes, the JavaScript editor makes an "update" by sending the markup to the server where the post is updated and the previous version is saved. The autosave occurs if I make an addition or deletion to the text. If no changes, then no saving. Old versions exist for comparing and reverting.

If I create or update within a textarea box, then I need to click the save button to apply changes periodically. And then I need to click the edit link to continue making changes.

If it's a quick change or an update that requires minimal changes, I'll use the textarea box. But if the update will take longer, then I use the JavaScript editor.

From assignment to publication, text can pass through several different editors, some of them made to handle richly formatted text in one particular way, some made to handle it in another, and some of them … not really made for that at all.

Oh my gosh. That's unbelievable.

A story that begins in Microsoft Word might then be pasted into Gmail and emailed to an editor using Outlook; from Outlook it might be pasted again into Google Docs, before finally being pasted into the text box of a proprietary CMS, for example.

Stunning, especially in 2016. But the blame does not belong to those computer programs. The blame belongs to the people who tolerate that process. Obviously, problems can occur. I would be shocked that a story got published correctly.

Processes like that need redesigned. Standards need to be adopted.

In the process, it will likely have picked up (or lost) stray bits of HTML formatting — odd
and tags used by one text editor but not another — even if the text as written remains intact.

No kidding.

This extra HTML junk, or lost formatting, is extremely annoying, especially for copy editors and web producers, but in most cases it’s not a huge deal.

When Gawker updated its content-management system, its headlines no longer supported strike-through, and this post now lives on under a totally incoherent headline.

A style guideline should include NOT using strikethrough markup because it can be hard to read or confusing to the reader. It's better to make a footnote or use a simpler method to indicate a correction.

In the past, I have used the HTML insert tags to underline text, but I stopped doing that, finally, since on my other web publishing apps, I have switched back to underlining links that exist within the body of an article. And underlined text done with the insert command can make the reader think that it's a web link.

The CSS used here at JotHut does not yet underline links within the body of an article. That's the way links were displayed in the beginning of the web 25 years ago.

The confusing issue with strikethrough:

Strike-through, where the formatting is meant to communicate that the text actually means the opposite of what you’re reading, is an obvious example.

Text exists, but it means the opposite because it has a line through it. What?

Yeah, I get it, and I have used strikethrough many times in the past, but now I accept it as a bad UI/UX choice within a web article.

We should be clear and say what we really mean, instead of creating a formatted line where it's left up to the reader to decipher correctly. Keep it simple and don't use strikethrough and insert (underline) to indicate some kind of emphasis.

But it applies to block quoting, too. From a visual perspective, block-quote formatting is superior to your standard quotation mark — it’s a highly visible signal that the offset text should be understood differently than the surrounding paragraphs.

True. And within text markup of this post that I am creating, I'm using my q./q.. block quote command to format the text differently within the browser to indicate that the content comes from elsewhere. My quote block uses divs, which I'm moving away from within my Wren blogging app.

I could have used Textile's bq. command at the start of each paragraph to quote. Textile also offers a bq command that is used once but applies to all paragraphs after until another Textile command is used.

For a large block fo text, tt's easier to use a fence like command, such as my q./q.. because I only have to apply the commands at the start and end of the text block. But using the bq. or Markdown's greater-than sign on each paragraph may take a little longer to markup, but it's clearer because I don't have to search up or down the article to see if the text was part of a fence-like command.

I like Textile and Markdown. Most of my web publishing apps support both. This past winter and spring, I used Markdown more at ToledoWinter.com to get used to it and to simplify my formatting of articles.

Actually, instead of only Markdown, my apps support MultiMarkdown, which allows adds footnotes, tables, and definition lists, along with other options. And sometimes or most of the time, I "flavor" my Markdown with some Textile-like commands or with behavior that I'm used to, such as preserving newlines. But I also provide options to disable this behavior.

Anyway, I prefer typing with plain text, using Textile, Markdown/MultiMarkdown, HTML, and my own custom formatting commands.

I don't like Markdown's use of spacing as formatting commands, since those "commands" cannot be seen.

What the nymag.com wrote indicates that a lot of significant changes need to be made to simplify the process.

But when considered in light of the particularity with which different browsers and email clients render formatting, and the ease with which formatting can be stripped entirely when copying and pasting, it becomes a liability. The humble quotation mark is unlikely to suffer the same indignities as the flashier
tag when copied or pasted. Tags are no substitute for punctuation.

Don't share story text within the body of an email message. Using Markdown's or Textile's blockquote formatting commands in addition to double quotes might be a good rule.

Would Markdown's greater-than sign get lost in all of that shuffle listed by the nymag.com writer? It might get lost, since it is a greater-than sign, which is used to close HTML tags. It seems that Textile's bq. command is safer.

But this comes back to NOT using the CMS to manage the entire process. Relying on email for this kind of process is so 1990s.

None of which is to blame the formatting, or the CMS, or the terrible tools we’ve developed to make publishing “easier,” for the Daily News’s error: King’s editors had a responsibility to ensure that his accurate sourcing was reproduced when published, no matter the vagaries of their CMS. (King, too, should probably have been reading his articles once they were published.)

Multiple stories exist.

Is it a CMS problem, or do the writers and editors resist change and prefer to use familiar tools, regardless of the clunky workflow that they create?

Maybe writers and editors change jobs so often that they don't want to take the time to learn yet another CMS, therefore they use Microsoft Word, Google Docs, Gmail, Outlook, and other common tools that they can use at their next job. And maybe the media org cannot convince its employees to use the CMS, and the org gives up and just says get the job done however possible.

Whatever the reasons, it's a failure at many levels.

The writer concludes with whining excuses.

But a CMS that strips formatting — a specific and important kind of formatting — is setting up overworked editors to fail. To the extent that we rely on programs to do certain kinds of publishing work — and to the extent that we try to communicate meaning using HTML-formatting rather than "hard-coded" orthography — we’re asking to be misinterpreted.

A 2014 article that supports using HTML strikethrough.

http://www.poynter.org/2014/rejoice-gawkers-king-max-rejects-the-strikethrough-correction-with-good-reason/246197/

I may have agreed with using strikethrough in 2014 also, but now I believe the reasons are flawed. The focus should be on design and making something easy to use and understand, including plain text that is read within an editor and HTML text that is displayed within a browser.

If someone is unfamiliar with the markup commands, then it could be difficult to understand the meaning of strikethrough in the raw markup file. A footnote or some other clear way to explain the correction will be easy to understand within the raw markup. And more importantly, replacing strikethrough with something simpler and more obvious will be better for the reader.

Using only strikethrough formatting provides no details about what's going on within the raw markup nor the HTML page. It's up to the reader to figure it out.

We should not heap more work on the reader. If writers and editors complain about being overworked, then don't make the readers have to work a little harder to understand something.

It may seem minor, but not using strikethrough only requires a small amount of additional text to explain clearly what the writer means.

Reader first. Writer's fun a very distant second.

From the Poynter article:

Reasons for striking the strikethrough

First, he notes that the strikethrough does not always show up for readers, which is an undoubtedly important point:

"It’s HTML styling, and it gets stripped in Google searches, RSS, tweets, through copy-pastes, etc., completely fucking up our meaning, especially in headlines"

"We should strive to make our writing clear and precise even absent any text formatting," Kaiser Read wrote.

Boom. Design with text. Say what you mean. Don't rely on formatting and the reader to understand.

More:

If you use strikethrough to make a correction and it doesn't show up across all platforms, then it's no good. The act of correction has been defeated.

Another concern with strikethrough corrections is that this push-button fix actually introduces an element of complexity. The Post's corrections policy distinguishes between "major errors" and "minor errors," and says the strikethrough is good for the latter.

Who gets to decide when something is major or minor? The journalist who made the mistake? Uh-oh.

By creating two classes of error, you're adding another layer of decision making to the correction process. Is this a strikethrough correction or an add-it-at-the-bottom-of-the-post correction?

This opens to door to delays and new problems.

Keep it simple and people will offer corrections more frequently. One style, for all errors.

Yes, I have used the strikethrough as a jokey hack in my ToledoTalk.com posts.

I'm also falling out of love with the strikethrough correction because, as the Caliph of Corrections notes in his memo, the strikethrough is also used as a way to make a joke. He is also correct that "Jokes made using strikethrough are generally not worth saving."

Unfortunately, these jokes are made often enough to muddy the water for a strikethrough correction. Why take the chance that people think you're doing a funny-ha-ha strikethrough and not a dead serious correction?

More:

One last argument against strikethrough corrections: they can ruin the flow for a reader, and get in the way of a more complete correction.

As a corrections nerd, I love that a strikethrough correction shows up exactly where the error occurred. But as a reader, it can be something of a speed bump.

There's a better way to provide the context of an error and to offer a correction that gives more to the reader.

See the asterisk at the beginning of the correction? I call that the Slate asterisk because they have been using it for many years in corrections.

As shown by Slate and now Gawker, a great way to do an online correction is to add an asterisk at the end of the sentence where the error occurred, and then to put the correction at the bottom of the text, with another asterisk.

This means you've connected the context and correction for the reader — and you have more space to offer as much information in the correction as is needed.

https://twitter.com/ShaunKing/status/722517618561835009/photo/1?ref_src=twsrc%5Etfw

Here is where I properly attributed to @FiveThirtyEight. Notice I link, credit them, and include block quotes.

Yes, but he did so within the body of an email message. That should be the discussion too. Why did Shaun file his story within the body of an email and not within the CMS or at least as an attachment to the email?

Man, I despise Twitter's web design. It's amazingly bad. It's hard to follow a discussion. Why would Twitter think that using a pop-up display for a tweet or thread is good design?

http://www.nydailynews.com/news/national/king-top-trending-topic-lie-article-1.2611108


http://jothut.com/cgi-bin/junco.pl/replies/69152

https://medium.com/@jotham.sederstrom/regarding-shaun-king-and-the-daily-news-e458523367ce#.kohq1n7yn ---- http://mediagazer.com/160421/p6#a160421p6 #media #writing #cms #design
From: JR's : micro blog - Apr 21, 2016 - reply

16 replies
JR: "... sloppy editing on my part and a formatting glitch that until Tuesday I had no idea was systematically stripping out large blocks of indented quotations each time I moved Shaun’s copy from an email to The News’ own Content Management System ..."
- 20 hrs ago - # - reply

JR: Seems like an odd workflow for 2015-2016, and how could the CMS glitch go unnoticed for so long?
- 20 hrs ago - # - reply

JR: "... distracted with another of the many responsibilities I juggled as an editor." ---- more proof that in my opinion multitasking means doing many things with mediocrity.
- 20 hrs ago - # - reply

JR: "On any given day I was tasked with editing not only Shaun’s column but roughly 20 other news stories from five reporters, all of whom filed early and often." -- wow. 4 stories per reporter per day. Quantity over quality? Possibly a workflow design issue when managing that much content.
- 20 hrs ago - # - reply

JR: "Add to that a whiplash-inducing crescendo of breaking news, a handful of administrative responsibilities and the chaos typical of most newsrooms, and it’s easier to fathom how frequently focus can snap from one second to the next."
- 20 hrs ago - # - reply

JR: Excuses. But key phrase against multitasking: "focus can snap."
- 20 hrs ago - # - reply

JR: #gtd
- 20 hrs ago - # - reply

JR: "I take issue with Jim Rich’s assertion that these mistakes were “inexplicable.” They can happen easily if you’re not paying extreme attention to detail at every moment."
- 20 hrs ago - # - reply

JR: Yes, happens when trying to do too much at the same time. May need to rethink workflow or priorities within the org.
- 20 hrs ago - # - reply

JR: Here we go. The whining of the media industry. ---- "Many of us in the news industry are increasingly under pressure to deliver an ever higher volume of stories with ever fewer resources and let’s just say, that doesn’t help."
- 20 hrs ago - # - reply

JR: "False Plagiarism Accusation Against @ShaunKing Shows Dangers of Online Mob Journalism" ---- https://mobile.twitter.com/ggreenwald/status/722841312261607426 ---- come on. The outrage is selective. The deranged social media mob claims many victims.
- 20 hrs ago - # - reply

JR: https://theintercept.com/2016/04/20/false-plagiarism-accusation-against-shaun-king-shows-dangers-of-online-mob-journalism/
- 20 hrs ago - # - reply

JR: https://medium.com/the-30/on-the-shaun-king-mess-and-the-editor-in-the-age-of-churn-634b5abe666d#.cyolbnzeg
- 7 hrs ago - # - reply

JR: http://nymag.com/following/2016/04/dont-trust-your-cms.html
- 7 hrs ago - # - reply

JR: Blame the geeky programmers. Good one. I say, blame Craigslist.
- 7 hrs ago - # - reply

JR: "Publishing to the web is, in many ways, hugely more complicated than publishing on a printing press." --- wrong, at least for me and my web publishing apps. Maybe the CMS apps for media are too complex
- 7 hrs ago - # - reply


http://www.mediaite.com/online/new-york-daily-news-hires-columnist-blacklivesmatter-activist-shaun-king/

From JR's : articles
4793 words - 29024 chars - 26 min read
created on
updated on - #
source - versions

Related articles
Micropublishing - Mar 24, 2015
Writing-related links - June 2014 - Jun 24, 2014
Examples of nicely formatted Medium.com stories - Apr 05, 2014
Crafting an online media story - Mar 03, 2014
Snarky, tear-down content - Dec 17, 2014
more >>



A     A     A     A     A

© 2013-2017 JotHut - Online notebook

current date: Jul 25, 2017 - 10:41 p.m. EDT