Wiki Patterns
grow your wiki
EditButTheIntranet
Synopsis
The "ButTheIntranet" pattern is one propogated by a webpageChampion to discourage wiki use, perhaps because they are familiar or vested in the "old" way of doing things on the world-wide-web.
Symptoms
- "But we've just spent three years and $$$$ building an Intranet for this content., why do we need a Wiki?"
- "There are certain documents that you don't want to let just anyone edit. Why put those on a wiki?"
- "You can't make production quality webpages using a wiki platform"
- "You can't make a fully functional web portal on a wiki platform"
Root Causes
The webpageChampion is someone who fills the following roles for the organization's intranet, and perhaps sees wiki as a threat to their ability to do their job or a waste of time.
- Controls publishing of web content
- May be held accountable to show a "success" or a "return on investment" for web and/or wiki content
- Doesn't have invested interest in promoting innovative or collaborative thought
In the a way similar to a wikiNoob they may only see or re-create pre-existing ways of interacting with content:
Resolution
- you must first convince this person that there is a deficiency with the static intranet or dynamic, but technical, portal system they implemented, but you can't do that by directly attacking 'their baby' project.
- demonstrate additional metrics the webChampion can highlight, in addition to their familiar 'number of visitors', such as 'most collaborative page', most active authors
- propose that they retain a 'publish' control, but increase their responsibility (or SLA) to publish content from ANYONE in the organization in a timely manner. They will soon be overwhelmed by the amount of participation that they simply 'approve' without comment or even review, and by that point, they may be more comfortable with the system.
- engage the webpageChampion to address and be accountable for the companies knolwedge innovation or collaboration objectives.- show how the wiki can seamlessly integrate with their 'baby', but offer additional functionality that they would not have the resources to re-invent or re-implement themselves.
Adoption Patterns
Adoption Anti-Patterns
Wikipatterns.com is sponsored by Atlassian Software, creators of JIRA, Confluence, Bamboo and Crowd
Designed by Headshift Ltd
Maybe a distinction needs to be made
Corporate website - fairly static
Intranet site - changes occasionally
Wiki - very frequent changes
As data matures, maybe as a result of a design process (or a refining process) the data becomes complete and can then be made available on more static sites. The wiki being the tool for creation and frequent modification during the design phase
While the comment about not understanding the nature of thought may be apt in some circumstances, it's also true that websites don't only represent thought, especially its critical and/or imaginative dimensions.
They also represent policies and decisions, and these generally need to be portrayed as finalised statements, as in the traditional form of publishing embodied in a corporate website or intranet site.
The more common mistake, however, is to assume that ALL information is of this type, when in fact the vast majority is not.
The challenge is changing attitudes sufficiently to have an open discussion about which documents fall into which categories, and how to keep the more static documents in touch with the critical/creative attitude of the wiki through a process like the one metzlert suggests.
I am running into this for a grassroots organization I am starting at my global software company. One of the main benefits that I see for wikis with my group is a low adoption barrier and easy maintenence. With company intranets especially, very few people have access to contribute or alter content, and they are not usually saavy designers or information delivery people. With a wiki users don't need alot of training to get up and running.
Another version of this is the SharePoint Hooligan...
They also represent policies and decisions, and these generally need to be portrayed as finalised statements, as in the traditional form of publishing embodied in a corporate website or intranet site.