In my last post on wikis, Mark Baker added an astute comment:
I'm not a wiki fan myself — I'm a structured text guy bred in the bone — but I am fascinated by the trend, and by the variety reactions to it.
Wikis started more as a cultural statement than a technology. They were a tool for the democratization of content, the intent being to eliminate the distinction between reader and writer. In the wiki philosophy, every reader was also a writer, there was no ownership of content, and not notion of a final, finished, of blessed editions of content. The wiki was always open, always evolving, and blessed only by the consensus of the community. Today, it would style itself “occupy content”.
What wikis have become, largely, is an unstructured CMS with only one face. A traditional CMS has two faces: one toward the author, and one toward the reader. A wiki has only one: the same face toward reader and writer, with every page having an edit button on it. Except that today the edit button is locked or hidden from most users. The distinction between reader and writer has been reintroduced and enforced. The original wiki philosophy has been rejected.
Still, the stated motive of most people who adopt wikis for technical communication is to allow more collaboration and to open up authoring to a wider community. So some shadow of the wiki philosophy is still at work. That being the case, I think there are a couple of things that people need to understand about the wiki philosophy and its consequences.
The first is, if you want to crowdsource effectively, you need to be open. People need gratification. If the content they contribute disappears into a black hole of moderation and curation, they don't get the immediate gratification of seeing their work published, and gratification delayed is gratification denied. You won't get a lot of content from the crowd unless you let the crowd publish.
The second is a consequence of the first. The implication of the idea that there is no distinction between reader and writer is that the reader has to take more responsibility for what they read. The old contract between the writer and reader of technical content, that the published content had been vetted and could be relied upon uncritically, cannot be sustained in a crowd-sourced world. The reader of a wiki, like the reader of any Internet content, has to assume some responsibility for vetting the content they receive.
By and large, readers do understand this. It is the responsibility they accept every time they type something in a Google search box. The simple fact of the matter is that readers prefer unblessed content that addresses their task and is available now over blessed content that does not cover their task or will not be available until next year. Timeliness and coverage trump all other considerations most (thought definitely not all) of the time.
The question for tech writers is, is there a place in your hearts, and in your company's relationship with its customers, for unblessed content that enhances coverage and timeliness?
I like Mark's comment for several reasons. He brings up several key points with wikis:
When we talk about wikis, it's important to see them as more than just another authoring platform. As a reader, knowing that I can change the text alters my sense of the text. It is no longer the absolute word on the matter. I can be a part of the conversation; I can change the message. It is my content as much as another's.
And making those changes immediately, seeing it published instantly, is gratifying. It's empowering, almost to the level that the printing press changed the distribution of knowledge. Wikis take it to another level, allowing every reader to also be a publisher. Tapping into the knowledge that every reader has, inviting the reader to share that knowledge, and trusting the reader that he or she will shape the content responsibly, isn't just a shift to another tool. It's an entirely different way of thinking and interacting. It's the 21st century interactive read/write web model. It's a model that acknowledges that the sponsoring organization doesn't have all the knowledge, but that individuals located in disparate regions also have important contributions to make -- and that they should share those contributions. Wikis democratize the knowledge landscape, allowing everyone to speak without pre-filtering editorial control.
This is why, like Mark, I am also fascinated by wikis. In an organization like mine that is traditionally top-down, with careful filters on outgoing messages, a wiki is a complete anomaly. And yet, it is also not an anomaly. Latter-day saints have a history of volunteering, of consecrating their efforts for the community. In the nineteenth century, members would contribute their time, talents, and own funds to build temples (which took years), or to work in fields. In this sense, a wiki is a perfect fit. It is a knowledge project rather than a physical structure project.
Mark also brought up the fact that he is a "structured text guy bred in the bone." I was talking with Scott Abel last week, and as Scott was explaining something about structured authoring, I brought up this question: Don't you see wikis and social media as going in the opposite direction of structured authoring?
I know we need to put our content into structured forms so that it can be leveraged into other channels we need to publish to (ePub, mobile, web, print, and more). But it's impractical to ask people in the community -- who are not technical writers and who do not have your same toolset and knowledge -- to write in structured formats. Taking contributions from the masses requires you to simplify your authoring model. You end up with an either/or choice. Either you can go the structured authoring route, or you can go the social collaboration route.
In response, Scott mentioned a point similar to what Mark says about content management systems. The only thing that really separates a wiki from a content management system is that the content management system hides the Edit button from the user. If I were to give you login information for my WordPress blog, for example, you would see an Edit link below the post title. You could log in and make changes to what I'm typing right now. With one flip of the switch, I could simply convert this WordPress content management system into a wiki-like platform, breaking down the division between reader and writer, and accomplishing the same end. Right?
What's more, if the content management system stores content in XML, or relies on some other structured authoring interface for writing content (you can export from WordPress to DITA, for example), it would solve the problem that I describe above about the divergence of structured authoring and social media. Right?
Sort of. I would like to see more content management systems move in this direction. I'm not that familiar with all the various content management systems out there and the number of wiki-like interfaces they potentially offer. In my experience, many times the content management system is behind a firewall or has other security restrictions. Many content management systems may not provide the inviting simplicity that traditional wikis offer. And licensing is also another issue. As a result, more often than not, users cannot simply click an Edit link and start updating content. However, I think that it's only a matter of time before this becomes more normal.
What do you think? Do you agree with Mark's observations about wikis? Are socially collaborative tools and structured authoring going in different directions?
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.