Wordyard

Hand-forged posts since 2002

Archives

About

Greatest hits

Dear publishers: When you want to switch platforms and “redesign” too? Don’t

by

4344254749_b400919e68_o

In my work at Grist, I had a rare experience: We moved an entire publishing operation — with a decade of legacy content, in tens of thousands of posts — from one software platform to another. And yet, basically, nothing broke. Given the scars I bear from previous efforts of this kind, this was an exhilarating relief.

I promised my former colleague Matt Perry (then technical lead at Grist, who bears much responsibility for our success in that move, along with my other former colleague Nathan Letsinger) that I’d share notes with the world on what we learned in this process. It’s taken me forever, but here they are.

Say you run a website that’s been around the block a few times already. You’re going to move your operation from one content management platform to another. Maybe you’ve decided it’s time to go with WordPress. Or some other fine system. Or you’re lucky enough, or crazy enough, to have a developer or a team of coders who’ve built you a custom system.

Then you look at your site’s design: the templates, the CSS, the interface, the structure and navigation all the stuff that makes it look a certain way and behave a certain way. You think, boy, that’s looking old. Wouldn’t it be great to spiff everything up? And while you’re at it, that new platform offers so many exciting new capabilities — time to show them off!

It seems so obvious, doesn’t it? You’re already taking the time away from publishing, or community-building, or advocacy, or monetizing eyeballs, or whatever it is you do with your site, to shore up its technical underpinnings. Now is surely the perfect moment to improve its public face, too.

This is where I am going to grab you by the shoulders and tell you, sadly but firmly and clearly: NO. Do not go there.

Redesigning your site at the same time you’re changing the software it runs on is a recipe for disaster. Here Be Train Wrecks.

Don’t believe me? Go ahead then; do your redesign and your platform move at the same time! Here’s what you may find.

You’ve just split your team’s focus and energy. Unless you have a lot of excess capacity on the technical side — and every online publisher has, like, technical folks sitting around with nothing to do, right? — your developers and designers are already stretched to the limit putting out everyday fires. Any major project is ambitious. Two major projects at once is foolhardy.

You’re now stuck creating a big new design in the dark. That new platform isn’t live yet, so you can’t take the sane route of implementing the new design in bits and pieces in front of real live users. Your team is free to sit in a room and crank out work, sans feedback! Good luck with that.

You’re now working against the clock. Back-end platform changes are full of unpredictable gotchas, and almost always take longer than you think. That doesn’t have to matter a great deal. But the moment you tie the move to a big redesign project, you’re in a different situation. More often than not, the redesign is something that everyone in your company or organization has an investment in. Editors and creators have work with deadlines and must-publish-by dates. Business people have announcements and sales deals and marketing pushes that they need to schedule. The stakes are in the ground; your small-bore back-end upgrade is now a major public event. This is where the worst train wrecks (like that one at Salon over a decade ago that still haunts my dreams) happen.

Painful as it may be, and demanding of enormous self-restraint, the intelligent approach is to move all your data over on the back end first, while duplicating your current design on the new platform. Ideally, users won’t notice anything different.

I’m fully aware that this recommendation won’t come as news to many of you. It’s simple science, really: Fiddle with only one variable at a time so you can understand and fix problems as they arise. I’m happy to report that this approach not only makes sense in the abstract, but actually works in the field, too.

(Of course, you may wish to go even further, and eliminate the whole concept of the site redesign as a discrete event. The best websites are continuously evolving. “Always be redesigning.”)

Mr. Daisey and the Fact Factory: my take at Grist

by

We interrupt this long blog-silence (more on which soon) to note that if you wanna know my take on the Mike Daisey/Apple/This American Life thing, I’ve just posted over at Grist on it.

My career started with writing about theater and specifically solo performance, moved into technology coverage, then took a turn into ethics and accuracy in journalism, and is now focused on sustainability and the environment. So Daisey’s story touched pretty much every one of my nerves.

Here’s an excerpt:

The temptation to round corners, to retouch images, to make a story flow better or a quote read better, faces every creator of non-fiction at every single moment of labor. And we all do it, all the time. We do it by varying degrees. We slice out “ums” from quotes. We leave out material we deem extraneous. No matter how much we verify of the facts that we think are salient, we can never verify everything.

But there are some compasses we can follow and some precedents we can observe. We don’t create composite characters (see: Janet Cooke) — or if we do, we explain exactly what we’re up to. We don’t say we’re reporting from one city when we’re sitting in another (see: Jayson Blair). We don’t simply invent stuff because it makes such great copy (see: Stephen Glass). We don’t invent a fake persona because it “makes people care” (see: Amina Araf).

The distinction between cosmetic changes and substantive fabrications is relatively easy to make. Storytellers get into trouble when they start to write themselves blank checks to “improve” on reality because the ends (in Daisey’s case, “making people care”) justify the means (in Daisey’s case, making shit up).

The whole thing is here.

WSJ Social: When news apps want to steal your face

by

I read about WSJ Social, the newspaper’s experiment at providing a socially driven version of itself entirely inside Facebook, and thought, hey, I should check it out. So I Googled “WSJ Social” and clicked on http://social.wsj.com. Since my browser was already logged in to Facebook, I was immediately confronted with a Facebook permissions screen. I captured it above for posterity.

Here is the problem: All I want to do is see what WSJ is up to. I might or might not actually want to use the product. But before I can proceed, here is what I’m asked to approve:

(1) “Access my basic information — Includes name, profile picture, gender, networks, user ID, list of friends, and any other information I’ve made public.” Well, this stuff is public already, right? I think I can live with this.

(2) “Send me email — WSJ.com may email me directly…” Hmm. I’m not eager to add to my load of commercial email and there’s no indication of the volume involved. But I’m not hugely protective of my email address — you know, there it is in the image above — so I guess this isn’t a dealbreaker.

(3) “Post to Facebook as me — WSJ.com may post status messages, notes, photos, and videos on my behalf.”

Excuse me? You want to do what?

Forget it, NewsCorp. Ain’t happening.

Now, I fully understand that the app may be up to nothing terribly nasty — some or most of what it wants to do may be routine back-end stuff. But it doesn’t provide me with any confidence-building information. Tell me, WSJ Social: How often are you going to post under my account? And what kinds of messages are you going to send? How will I know you’re not going to spam my friends? How do I know the WSJ’s rabid editorial-page id won’t start posting paeans to Sarah Palin under my name?

Facebook permissions screens may have become as widely ignored as Terms of Service checkboxes and SSL certificate warnings. But the notion of the Journal (or anyone else) insisting on its right to “Post to Facebook as me” before it will even let me examine its news product is simply ridiculous.

UPDATE: On Twitter, WSJ’s Alan Murray responds: “Not going to happen. Standard permissions in order to allow WSJ Social to share stories you ‘like’ with your friends.”

My next chapter: Grist

by

After a wonderful couple of years writing Say Everything and another great couple of years building and launching MediaBugs, I’m returning to the world of editing: Starting today, I’m the executive editor of Grist.org, the pioneering green news website with the irreverent attitude.

It wasn’t entirely clear to me, after I left Salon four years ago, that I would ever take this kind of job again. It would have to be a very special organization: one that was trying to accomplish something important in the world; one that valued old-fashioned journalism and newfangled digital innovation; and one where the odd set of talents I’ve accumulated across my motley career could actually be put to work in useful ways.

Grist turned out to fit this bill in an almost supernaturally precise way. I first got to know the work Chip Giller and his team were doing there a decade ago at Salon, where we had content-sharing agreement, and I’ve continued to be fan of what they’ve built over the years. Now I have the privilege of taking Grist’s editorial helm at a moment that’s more critical than ever for the future of the planet — and more fluid than ever in the evolution of media.

Can you tell I’m excited?

It’s been a long day, so I think I’d better turn in — but not before pointing you to the sprightly post Chip wrote to welcome me to Grist, and the little note I wrote to introduce myself. There was also a brief press release with some kind words from my former colleague and sometime boss Joan Walsh.

And for those of you wondering about MediaBugs: It’s very much an ongoing project, though obviously I’m going to have less time to devote to it myself. I’ll be posting more here soon on its future, as well as offering a full report on its progress to date and some of the lessons we’ve learned from it.

The case of the New York Times’ terror error

by

[This article, which is a collaboration between me and Mark Follman, originally appeared on the Atlantic’s website. Since then it has been the subject of a MediaBugs error report filed by Frank Lindh. Yes, at MediaBugs, not only do we eat our own dogfood, we find it tasty!]

It is hard to describe the interview that took place on KQED’s Forum show on May 25, 2011, as anything other than a train wreck.

Osama bin Laden was dead, and Frank Lindh — father of John Walker Lindh, the “American Taliban” — had been invited on to discuss a New York Times op-ed piece he’d just published about his son’s 20-year prison sentence. The moment host Dave Iverson completed his introduction about the politically and emotionally charged case, Lindh cut in: “Can I add a really important correction to what you just said?”

Iverson had just described John Walker Lindh’s 2002 guilty plea as “one count of providing services to a terrorist organization.” That, Frank Lindh said, was simply wrong.

Yes, his son had pled guilty to providing services to the Taliban, in whose army he had enlisted. Doing so was a crime because the Taliban government was under U.S. economic sanctions for harboring Al Qaeda. But the Taliban was not (and has never been) classified by the U.S. government as a terrorist organization itself.

This distinction might seem picayune. But it cut to the heart of the disagreement between Americans who have viewed John Walker Lindh as a traitor and a terrorist and those, like his father, who believe he was a fervent Muslim who never intended to take up arms against his own country.

That morning, the clash over this one fact set host and guest on a collision course for the remainder of the 30-minute interview. The next day, KQED ran a half-hour Forum segment apologizing for the mess and picking over its own mistakes.

KQED’s on-air fiasco didn’t happen randomly or spontaneously. The collision was set in motion nine years before by 14 erroneous words in the New York Times.

This is the story of how that error was made, why it mattered, why it hasn’t been properly corrected to this day — and what lessons it offers about how newsroom traditions of verification and correction must evolve in the digital age.

[Read more…]

Recent work: NY Times’ 9-year-old terror error; local news ethics; Wikipedia

by

Sometimes your labor on a bunch of projects comes to fruition all at once. Here are some links to recently published stuff:

Corrections in the Web Age: The Case of the New York Times’ Terror Error — How did a 2002 error in the New York Times wreck a KQED interview in 2011 about John Walker Lindh, the “American Taliban”? And what does the incident tell us about how newsroom traditions of verification and correction must evolve in the digital age? MediaBugs’ Mark Follman and I put together this case study and it’s all here in the Atlantic’s fantastic Tech section. If you’re wondering what the point of MediaBugs is or why I’ve spent so much of the past two years working on it, this is a good summary!

Rules of the Road: Navigating the New Ethics of Local Journalism: I spent a considerable amount of time last winter and spring interviewing a whole passel of editors and proprietors of local news sites as part of this project for JLab, trying to find the tough questions and dilemmas they face as old-fashioned journalism ethics collide with the new shapes local journalism is taking online. It was a blast doing the interviews and fun assembling the results with Andy Pergam, Jan Schaffer and everyone else at JLab. It’s all on the website but it’s also available in PDF and print.

Whose point of view?: In the American Prospect, I used Wikipedia’s article on Social Security as an example to explore how Wikipedia’s principle of “neutral point of view” can break down. Here’s an excerpt:

Wikipedia says virtually nothing about the system’s role as a safety net, its baseline protections against poverty for the elderly and the disabled, its part in shoring up the battered foundations of the American middle class, or its defined-benefit stability as a bulwark against the violent oscillations of market-based retirement piggy banks.

This is a problem—not just for Social Security’s advocates but for Wikipedia itself, which has an extensive corpus of customs and practices intended to root out individual bias.

NY Times: “Paper of record” no more?

by

New York Times public editor Art Brisbane today addresses an issue that MediaBugs and I have been talking about for a year: the need for news organizations to maintain a record of the changes they make to published stories.

I’ve argued that posting such “versions” of every news story — the way Wikipedia and every open source software project does with their own work — would help newsrooms regain public trust and free journalists to update their work more vigorously while staying accountable.

Brisbane seems to agree, but sounds doubtful that the Times is going to do this any time soon.

Right now, tracking changes is not a priority at The Times. As Ms. [Jill] Abramson told me, it’s unrealistic to preserve an “immutable, permanent record of everything we have done.”

I know the Times has tons of claims on its resources. Jill Abramson has a million demands to juggle. But let me respectfully dispute her “unrealistic” judgment.

Versions of stories are just data. For the Times, or any other website, to save them is a matter of (a) storage space and (b) interface tweaks to make the versions accessible. Today, storage is cheap and getting cheaper, and Web interfaces are more flexible than ever.

Really, there’s nothing unrealistic about preserving an “immutable, permanent record” of every post-publication change made to every story.
Wikipedia — a volunteer organization run by a variety of ad hoc institutions — can do it. Any WordPress blog can do it. It seems peculiarly defeatist for our leading newsroom to shrug and say it can’t be done.

By making story versions “not a priority,” the Times is essentially abdicating its longstanding status as our paper of record as it makes the transition from paper to digital. I doubt that’s what its leaders intend to do. The more they ponder this, the more I think they’ll see that a versioning system for news is not only valuable but inevitable.

Three pillars of trust: Links, revisions, and error buttons

by

The journalism industry ships lemons every day. Our newsrooms have a massive quality control problem. According to the best counts we have, more than half of stories contain mistakes — and only three percent of those errors are ever fixed.

Errors small and large litter the mediascape, and each uncorrected error undermines public trust in news organizations. In Pew’s last survey in Sept. 2009, only 29 percent of Americans believed that the press “get the facts right.”

Yet the tools and techniques to fix this problem are known and simple. I’ve been working in this area for the last two years. Here’s a distillation of what I’ve learned: three basic steps any online news organization can take today to tighten quality control, reduce errors and build public trust.

    Link generously

    A piece without links is like a story without the names of its sources. Every link tells a reader, “I did my research. And you can double-check me.”

  • Read more on the value of links: In Defense of Links.
    Show your work

    The news isn’t static, and online stories don’t have to be, either. Every article or post can and should be improved after it’s published. Stay accountable and transparent by providing a “history” of every version of each story (a la Wikipedia) that lets readers see what’s changed.

  • Read a longer argument for the value of versioning.
    Or try out the WordPress plugin.
    Help people report your mistakes

    The Internet is a powerfully efficient feedback mechanism. Yet many news organizations don’t use it. Put a report-an-error button on every story: It tells readers you want to know when you’ve goofed. Then pay attention to what they tell you.

  • Get some report an error buttons at the Report an Error Alliance.
    Or use the MediaBugs widget.

Why aren’t these practices more widely adopted? Here are four reasons:

(1) Workflow and tools: In many newsrooms, especially those still feeding print or broadcast outlets, it’s still way too hard to fix errors or add links to a story for its Web edition. And content-management systems don’t yet offer corrections and history tools “out of the box.”

(2) Denial and avoidance: Other people make errors. Many editors and reporters don’t believe the problem is serious, or think it doesn’t apply to them. And most don’t understand how badly their Web feedback loop is broken.

(3) Fear of readers: Many journalists view readers as adversaries. The customer they feel they’re serving is an abstraction; the specific reader with a complaint is “someone with an agenda” whom they have a duty to ignore.

(4) Where’s the money? Many media companies are in financial free-fall. Correction systems and trust-building tools don’t bring in revenue directly, and they eat up product-development time and money.

These are serious obstacles. But journalists will never regain public trust unless we overcome them.

Ask journalists what sets them apart from everyone else sharing information online and we’ll say: We care about accuracy. We correct our mistakes. In a changing media economy that’s challenging the survival of our profession, we need to follow through on those avowals. Otherwise, we shouldn’t be surprised when Pew’s next biennial survey of public trust in the media shows even more dismal results.

[Crossposted from PBS MediaShift Idea Lab. This edition employs all three techniques I mention.]

Time to bake smart correction tools into news platforms

by

[cross-posted from the PBS MediaShift Idea Lab]

A window of opportunity is open right now for online journalists to build accuracy and accountability into the publishing systems we use every day. To understand why this is such a big deal, first hop with me for a minute into the Wayback Machine.

It’s the mid-1990s. Journalists have just arrived on the web. They’re starting sites like Hotwired and Pathfinder, Salon and Slate. They’re doing good work, but also, inevitably, making mistakes. Their customary corrections routine — post a notice in the next edition or issue — makes no sense in the new medium, where stories are just files on servers or data in databases, and fixes can take effect instantly and invisibly.

Editors at the dawn of the web understood they had to be accountable for changes they made to published stories, and so improvised a routine for handling substantive corrections: Fix the problem; place a notice on the story page indicating that you’ve fixed it; and — this step was only taken by extra-conscientious organizations — add a notice to a separate page logging the fact of the correction (and linking to the corrected story).

>p>Fast-forward to the present. The web’s publishing environment is vastly more complex, flexible and elaborate. But when it comes to corrections, virtually every news site still handles things the way we did 15 years ago: Go into the story, often by hand (i.e., by adding to the body of the story text), fix the error, and append a correction notice to the story top or bottom. Then, if your site has a separate corrections-listing page, go into that by hand and add the notice there. Insert any cross-links. Republish the story and the corrections page. And you’re finally done.

The process is cumbersome, to be sure; it’s also not smart. Most publishing systems don’t actually “know” that the story has been corrected. There’s no data stored that distinguishes a corrected story from, say, one that’s been altered in some other way. The typical content-management system software package will track each successive edit or revision to a document, but it doesn’t distinguish garden-variety edits from formal corrections.

For years now, I’ve dreamed of a smarter publishing software tool that would handle corrections intelligently and seamlessly as part of the publishing cycle and editorial workflow, rather than as a clumsy kludge. One goal, certainly, is to make editors’ lives easier. If corrections can be handled with less fuss, maybe news sites will be less reluctant to make them.

But an even more important goal is to give journalists and the public better information about corrections. Once corrections are treated as data, developers can do things with them — say, allow readers to sign up to be notified of corrections for a site, individual story or story category; or create display boxes that automatically link to the half-dozen most recent corrected stories. The ultimate purpose of all this is for news organizations to demonstrate accountability and transparency to a public that views them with sparse and dwindling trust.

Armstrong CMS project

So when I read about the new Armstrong CMS project, I got excited. Armstrong is an effort by the software teams at the Bay Citizen and the Texas Tribune to build a new-model, open source publishing system for local news sites. It’s working off the highly regarded Django content-management framework, funded by a $975,000 grant from the Knight Foundation, and building on existing work already in use at the two sites.

The Armstrong project has a chance to create a new standard for corrections for the entire field of web journalism. I asked Brian Kelley, the Bay Citizen CTO who is a co-leader of the project, whether Armstrong had plans for corrections yet. He suggested that, because many organizations have different needs, Armstrong’s open plug-in and extension options might be the best way to handle the corrections process.

Maybe so. At MediaBugs we certainly plan to explore this route with Armstrong as we have with other partners; our MediaBugs widget and WordPress plug-in are already in use on a handful of news sites.

But there’s a bigger opportunity for the Armstrong community here: They can build a smart correction-handling process into the heart of the tool they’re creating. The best practices in this area are widely understood and agreed upon; why not bake them into the technology? No one, to my knowledge, has done this before in a free, open source publishing system. (If there are proprietary systems that do a better job, I’d love to hear about them.)

Here are the basic features I’d want any corrections tool to provide:

  • Editors should be able to correct published stories by checking a box or clicking a button on an edit screen. If the system has a permissions hierarchy, then managers should be able to enable or disallow the option of making a correction.
  • Editors who are correcting a story are taken to a screen or overlay that lets them enter the text of a correction notice. The software would automatically record the date and time the correction was made.
  • Once the correction notice is entered, the editor is prompted to make whatever edits are required in the story text itself, and to save them. Editors would then have to republish the story, following whatever their site’s routine might be.
  • Ideally, a corrections system like this is part of a larger scheme for tracking and presenting all post-publication changes to each story. The database would record the changes made to a story as part of the correction process in a special way — that is, it would know that this particular revision is not just any old change but a formal correction.
  • Site designers and managers have the option of building a self-updating corrections page that automatically pulls in corrections notices and links back to the corrected stories.

That’s it! None of this is particularly challenging as programming or design work. My experience is that when I describe what’s needed to most developers, they’re not interested — the problem’s too “trivial.” Maybe it is — but not to the editors I’ve talked to, who groan about the pain their software inflicts on them whenever they try to do a correction the right way.

Each time we rewrite the software used to publish news on the web we have another chance to raise the bar for the whole field. I’m crossing my fingers that Armstrong will be the project to make smart corrections a reality.

Why journalists should think twice about Facebook

by

Facebook's journalism panel: O'Brien, Milian, Zaleski, McClure (photo by George Kelly)


At Facebook last Wednesday night, a panel of four journalists — Laura McClure of Mother Jones, Katharine Zaleski of the Washington Post, Chris O’Brien of the San Jose Mercury News, and CNN tech writer Mark Milian — talked about how they use Facebook as a tool for journalism. What they said was smart. I’d probably do most of the same things were I in their shoes.

But I had a question for them, and I didn’t get called on to ask it, so I’m going to ask it here. The question goes like this: Everything that journalists are doing on Facebook today — engaging readers in conversation, soliciting sources, polling users, posting “behind the story” material — is stuff they could just as easily do on their own websites. So why are they doing it on Facebook?

One answer is obvious: That’s where the people are! Vadim Lavrusik, a journalist who recently joined Facebook to work on its outreach to the media world, said as much. And it’s true: there are millions of people on Facebook, and Facebook makes it convenient to communicate with them. What’s the problem?

I’ll get to that. But there are other answers to the question, too. Many publications find that their interactions with their readers on Facebook are more civil and valuable than those that take place on their own websites. That, they typically believe, is because Facebook makes users log in with their real names and identities. Finally, individual journalists increasingly find it valuable to build their social-media networks as a hedge against the collapse of the institutions they work for. (“Who owns the ‘social graph’ you build on company time — you or your employer?” is one of those fascinating questions that most newsrooms have barely begun to grapple with.)

We can accept that all these answers make solid sense and yet still feel a little uneasy with media companies’ rush to shovel energy and attention into Facebook’s vast human scrum. Here’s where my uneasiness comes from: Today Facebook is a private company that is almost certainly going to sell stock to the public before long. It will have quarterly earnings reports to make and pressure to deliver to investors. It is run by almost impossibly young people who have never had to deal with any business condition other than hockey-stick-curve growth. For the moment it appears to be trying hard to operate as a neutral and open public platform; its constant tinkering and rethinking of the design and functionality of its services can be maddening, but so far have tended to be driven by a serve-the-user impulse.

That won’t last forever. There are plenty of people waiting to cash in on Facebook’s success, and more in the wings, and they will expect the company to fulfill its inevitable destiny — and “monetize” the hell out of all the relationship-building we’re doing on its pages.

This is the landscape onto which today’s journalists are blithely dancing. I understand why they’re doing it, but I wish the larger companies and institutions would think a little harder about the future.

The web itself is the original social network. Why would you ask reporters to connect with your readers on Facebook if you aren’t already encouraging them to do the same thing in the comments on your own website? If your comments have become a free-fire zone, why don’t you do something about it? If you’ve hired a “social media manager,” great — but why didn’t you hire people to manage your own comments space?

By moving so much of the conversation away from their own websites and out to Facebook, media companies are basically saying, “We did a lousy job of engaging readers under our own roof, so we’re going to encourage it to happen on someone else’s turf.”

You could argue that what news organizations are doing is just like telling your friends, “I can’t invite you over for drinks because our place is such a mess. Let’s meet at a bar!” Maybe. Then again, it might be like saying, “We let our neighborhood go to hell and didn’t do anything about it. Time to move to the mall!”

Facebook is on a fantastic roll today. It’s positioned to dominate the next decade of online evolution the way Google and Microsoft respectively dominated the previous two. It can’t be ignored and I wouldn’t suggest doing so. But it’s not the public sphere, not in the way the Internet itself is. It’s just a company. I hope every editor, reporter and news executive remembers that as they try to get their conversations hopping and their links shared.

Photo by George Kelly