This is the future of technical communication
First, read this article in the New York Times about the struggle to keep a reporter’s kidnapping quiet:
For seven months, The New York Times managed to keep out of the news the fact that one of its reporters, David Rohde, had been kidnapped by the Taliban. But that was pretty straightforward compared with keeping it off Wikipedia.
Now, think about these issues as applied to technical communication. Let’s assume that your organization has online community — forums and a wiki, maybe. Technical communicators are responsible for monitoring and managing the community. Under what circumstances do you delete information? How do you respond when:
- Information is inaccurate
- Information is unflattering
- Both
What if the information is accurate but incomplete?
What if someone describes a way of using your product that could cause injury, even though it’s technically possible? Do you delete the information? Do you add a comment warning of possible injury? What if the reader sees the original post but not the comment?
In the absence of safety concerns, I think that accuracy must win. Thus, as the information curator, you have a responsibility to correct inaccurate information. If the inaccuracy is truly dangerous, you may need to edit the post directly. Make sure that you disclosure what you’ve done with brackets. For example:
I like riding my scooter down mountains, especially without guardrails. Wheee! [This is a really bad idea because You Might Die. -moderator]
or
I like [really bad idea redacted by moderator]. Wheee!
Deleting unflattering (but accurate) information will probably backfire on the organization. Instead of censoring negative content, try addressing the concern being identified. Think of an impolite forum post as customer feedback. Does the poster have a valid point? Can you fix the problem that’s been identified?
I hate your scooters. They don’t come in enough colors. And they suck.
What colors would you like to see? We do have two dozen available, see this list.
– Joe in TechComm
The life-or-death issues around Mr. Rohde’s kidnapping are relatively straightforward. We are likely to have much more difficult judgment calls in typical technical communication. Imagine, for example, that information were being suppressed because it criticized security arrangements and not because of safety concerns for the reporter. In that case, I think we can agree that Wikipedia’s response would have (and should have) been different. What would an equivalent scenario look like in your organization?
Anne Gentle
The other day, I found a great scenario of what you’re describing. A lead writer at Adobe doesn’t suppress the limitations of the product he documents. He handles it in a really classy way on his blog. In his blog he has more freedom to write this way, it seems. For the example, check out http://blogs.adobe.com/indesigndocs/2009/03/endnotes_in_indesign_cs4.html and see his lead sentences: “Whenever people ask if they can create endnotes in InDesign, I have to explain the same sad story. No, InDesign has footnotes not endnotes, but you can download a plug-in . . .”
His judgment call was great, and I believe the whole scenario is one we’ll see more and more of if writers are given the correct outlets to offer these messages outside of the “vetted” documentation. The wonderful part of the story is that he weaved in information from support forums and then a user posted a script that automated the procedure he describes in the blog entry. I wrote up the “information trail” in a blog entry on my blog at http://justwriteclick.com/2009/06/14/does-designing-content-for-scanning-devalue-the-content/ if you want to read the whole story – I think it’s a great example!
Ellis Pratt
Judging from old TV crime series, the UK newspapers have often kept quiet about kidnappings and ransoms. Keeping it out of Wikipedia is a new development. I guess editors would argue that reporting a kidnapping could be seen as much as manipulation as not reporting it.