Wikipatterns – Table of Contents
Courtesy of Oliver Widder – Geek And Poke. Used with permission.
The chief difference between the wiki and more traditional content management (CM) or knowledge management (KM) systems is structure. Whereas most ECM and KM tools are built with defined structure in the form of proceses, workflows, and architectures, the wiki starts off with the minimum possible structure and grows a custom structure based on how each person, team, department, or project uses it.
It’s much easer at the outset to “sell” a tool – both in the financial and conceptual sense – that has defined structure, processes, and features because it can be presented as a solution for a specific need. It may do a good job meeting that specific need, but the tool runs into trouble when people inevitably try to apply it to other needs that may be very different from the initial need it was meant to meet. This is often the scenario in enterprises, and one of the main reasons why the promise of KM and CM systems hasn’t been fully realized more than a decade after they initially appeared on the scene.
What Happened to Knowledge Management?
Knowledge management came to prominence at the same time that technology was beginning to emerge and dominate organizational thinking. People were trying to figure out how to use technology to gather, organize, and manage knowledge in a more distributed way, but were working within the existing paradigm of hierarchical, centralized control. Because they were based on the prevailing thinking of the day, KM tools were designed to structure the knowledge process and allow people to maintain the hierarchical control they were accustomed to. They were also built to meet the needs of one type of user, which made it extremely difficult to reuse them in other areas, made content more difficult to access by anyone other than the users a system was designed for, and isolated users as they focused completely on learning processes and workflows in these systems.
Because of this emphasis on content, KM tools haven’t focused on connecting people naturally with as few boundaries as possible. Human intelligence and behavior is pattern-based but the rule and process based design of KM systems results in rigid interaction in the context of a defined workflow, i.e. one person authors a document and others read & approve it in a linear fashion. This doesn’t make sense in both a behavioral and practical context because it runs counter to natural patterns of human interaction. For example, what if you finished a document and sent it along the review & approval chain, then remembered something critical that you wanted to add? Would you add it and start the whole review process again, or just forget it? When you need to add or edit content you should be able to do so easily without any fear of disrupting a highly structured process.
Furthermore, those early KM systems tried to treat tacit knowledge (stored in peoples’ heads), as something that could be extracted and turned into explicit knowledge (written down), then turned back into tacit knowledge simply by another person reading it. The idea behind this approach was that peoples’ knowledge could be fed into the system, and housed completely separately from the people themselves for reuse by others. The flaw here is that tacit knowledge is intimately connected to the person in whose head it is stored, and people need to directly communicate with each other to transfer both tacit knowledge and the context surrounding it.
Something Wiki This Way Comes
The wiki is a complete departure from the principles of highly managed knowledge creation. Unlike KM systems, wikis focus completely on letting people work together online the same way they’d work in person, and approach knowledge as the product of that organic, non-linear human connection and collaboration. They deliberately leave out pre-built structure, complex procedures, workflows, and leave it up to the people using a wiki to define the ways they’ll use it and how they’ll organize their information. Ward Cunningham originally described the wiki as, “The simplest online database that could possibly work.” (Cunningham, 2002).
This does make a wiki more challenging to explain, especially to skeptics. It doesn’t just do one thing, and since people are used to thinking of software as having a specific use, it’s sometimes harder at first for them to grasp the potential of the wiki.
Once people understand it, it’s a much more valuable tool because the lack of rigid structure means it can be used to do almost anything people immediately think of. Over time, as people inevitably think of other uses, the wiki can handle them just as deftly. More rigid tools need a lot of tweaking and still won’t perform functions beyond their original design in an elegant, efficient way that makes people’s work easier. The wiki will do an elegant, efficient job because it is designed to do so in an intuitive way.
Taking the processes and structure out of the picture also makes the tool itself smaller, less technically complex and resource intensive, and more reliable. There’s less to buy because you can have an enterprise wiki running on a single server that costs just a few thousand dollars. There’s less that can go wrong with it because the underlying codebase isn’t as complex, and when problems do occur they can be fixed faster. There’s also less to justify financially, because an enterprise wiki that can support hundreds of individual wiki spaces and thousands of users costs a small fraction of the price of content management and knowledge management systems.
What Makes a Wiki a Wiki?
Let’s look at what’s unique about the wiki, and why it’s different from other collaboration and content management tools. In a general sense, a wiki does perform the functions of content management – creation, editing, organization, and storage – but it’s _how_ the wiki does these things that makes it unique.
Beyond the legendary ease of editing, perhaps the most important principle of the wiki is its conscious emphasis on using as little structure as possible to get the job done, and nothing more. A Wiki doesn’t force hierarchy, and this flies in the face of tradition where content management systems rely on a predefined hierarchy to organize information, and content is organized and accessed within the confines of this hierarchy.
Instead, an individual wiki starts out flat, with all pages are on an equal level. This allows people to create organization that makes the most sense for their work styles and the content they’re working on. For example, if a team is using a wiki to organize their meetings and projects, they might maintain two lists on the homepage: one consisting of links to pages containing meeting agendas & minutes, and the other containing links to pages for managing each project.
The Enterprise Wiki: Spaces and Pages
A wiki is the equivalent of a single website, and an enterprise wiki enables simplified management of multiple wikis for groups, teams, and projects. This is where the concept of spaces comes in. With Confluence, for example, the overall wiki is called the _site_, such as [http://confluence.atlassian.com]. Within that site are _spaces_ for different topics, groups, projects, and products. For example, if you were looking for information on plugins for Confluence, you would visit [http://confluence.atlassian.com] and choose the space called “Confluence Extension”. Inside that space, you would find a page for each plugin with information including the author, version number, description, download link, and documentation. Spaces are simply individual wikis within the enterprise wiki framework. They’re just like individual websites, and can even be accessed via their own specific addresses. For example, the Confluence Extension space URL is [http://confluence.atlassian.com/display/CONFEXT].
What makes an enterprise wiki attractive to organizations is the single framework for managing multiple wikis. An enterprise wiki is easier to manage and scales with growing demand for wiki use because creating a new space is a matter of a few clicks instead of having to install a new wiki each time one is requested. With regard to user accounts and access to wikis, an enterprise wiki is better for organizations because each time a new space is created, people can use the same account to access multiple spaces, instead of having to remember multiple usernames and passwords.
Furthermore, an enterprise wiki can connect to an organization’s existing LDAP repository, which contains the central database of user accounts for services like email and network access, which means the wiki login can be the same username and password each person already knows and uses. The simplicity of being able to use the same account helps drive user adoption, because it removes the potential barrier of having to remember another account, and helps make the enterprise wiki part of the mainstream set of tools people use.
For users, an enterprise wiki makes it easier to keep abreast of activity in all the spaces in which she or he is involved, because pages can be added to a list of favorites for faster access, and monitoring changes via email or an RSS feed. It’s also easier to get a general sense of what’s going on right when you login. The first page you see is a dashboard that gives you a snapshot of the entire enterprise wiki, with lists of all spaces you have access to, recently updates pages in those spaces, and pages you’ve marked as favorites. In addition you’ll see a tool to create an RSS feed of pages and spaces you want to monitor, quick access to your personal space and a link to start a blog post.
Features like central management and creation of spaces, ability to manage access to spaces via a permission system, connections to other enterprise tools, and the ability for users to access the wiki easily using existing accounts are critical to satisfying organizations’ requirements for a tool that is robust and secure enough to be part of their core infrastructure. For users, being able to use their existing username and password to access the wiki, monitor changes via email and RSS, and easily access multiple spaces are the kinds of features that make the wiki become an indispensable tool.
Editing Pages and Creating Content
A wiki makes creating content easy for people at all levels of technical knowledge. One of the hallmarks of wiki editing is wiki markup (Figure 3-1), a system of simple formatting prompts that is easier to learn than HTML code and faster than the toolbar and button based interfaces in word processing software.
For example, to make text bold using wiki markup, you’d just put asterisks at the beginning and end of the text you want to appear bold, *like this*. For italicized text, just put an underscore before and after _the text_. The idea behind wiki markup is to use such simple and intuitive notation that it’s easy to remember and can be done right from your keyboard as you’re typing.
Figure 3-1 Wiki Markup used in Confluence
I still remember my first encounter with wiki markup. For years I kept a simple to do list using just a Microsoft Word document open on one side of my display. In the document, I’d keep a sort of rudimentary bulleted list where the bullet point at the beginning of each line was simply an asterisk.
The first time I used a wiki, I created a bulleted list the exact same way and when I clicked “Save”, the asterisks next to each list item became true bullet points. I said, “wow!” and it was immediately obvious to me how much thought had gone into making this system respond to the way people like me were already working.
As wikis have grown more popular and entered the mainstream, wiki vendors have added WYSIWYG (what you see is what you get) editors to make the editing experience look and feel more like the Microsoft Word-style interface many people are used to. The primary benefit of a WYSIWYG editor is that it can ease the transition when people first start using a wiki, but here’s the rub: if it’s the only editing tool people use, the WYSIWYG editor offers a much more limited editing experience and prevents people from making the leap necessary to fully understand the power of a wiki.
Once people get used to the wiki, using wiki markup at least some of the time makes editing more efficient because of its simplicity, ability to be added with just a few keystrokes when needed, and the range of formatting it enables.
Here’s the HTML syntax for a standard hyperlink:
Here’s the same link in wiki markup:
Wiki markup is much simpler to write because it uses fewer characters to create the link. Creating the hyperlink using HTML required fourteen characters in addition to the web address (URL) and the display text, whereas wiki markup required only three. Also, in wiki markup the characters used are closer to natural writing. Placing brackets around the link is very similar to placing parentheses around text, and using a vertical bar to separate the display text and URL is the simplest way to format the two. Because people are so used to WYSIWYG editors and wiki markup has the word “markup” in its name, some people immediately assume it’s in the same realm of complexity as HTML and are afraid to try it.
So what does this mean from the perspective of growing wiki adoption? Encourage people to use what’s most comfortable, and educate them about wiki markup by emphasizing that it is a simple, quick shortcut for things like making text bold and italic, creating hyperlinks, or building bulleted and numbered lists. Using a WYSIWYG editor is a good way to get started with wiki editing, but wiki markup offers some valuable formatting options and the advantage of speed and simplicity and the two editing options used together pack a powerful punch.
Because wikis eschew strict hierarchy and formal structure, they allow for more evolutionary organization of content. Instead of one person arbitrarily deciding to put a file in a certain folder, such as on a shared drive, wikis allow people to tag pages with keywords describing their content. Tagging has emerged as one of the most effective ways to organize information because the organization is the result of a collaborative process where people create tags as needed to describe content, and instead of putting content in folders which is restrictive because a file can only reside in one folder, multiple tags can be assigned to a document by multiple people, which ultimately results in a better categorization of its content.
People can then search for individual tags, or combinations of tags, and wiki pages marked with those tags will be returned. What does this mean for your enterprise wiki? Different teams, groups, and project wiki spaces can have pages on a particular topic, and as long as they are tagged with common tags, they can easily be found, yet they don’t all have to be kept in the same place.
This kind of flexibility is one of the reasons why using a wiki improves collaboration. Those multiple teams working on different parts of a project previously had their content in multiple, disconnected places. One team was using email, another kept their documents on a shared drive, and a third had copies of documents scattered across peoples’ computers. Now thanks to the wiki and tagging, _all_ the information can be accessed by anyone in those teams with just a simple search.
With all this collaborative editing, how does a wiki keep track of changes to each page? Wikis maintain a revision history for every page that shows the time, date, author, and specific changes made with each revision. This allows people to see the progression of additions, changes, and deletions to a page. Additions are highlighted in green and deletions are highlighted in red so you can quickly see where changes have been made to a page.
The revision history even allows you to revert a page back to an earlier version if necessary. Let’s say you’re working on a document and someone mistakenly deletes part of the contents of a wiki page. You can just access the revision history and restore the previous revision of the page with one click. What’s interesting here is that whenever a change is made, the revision history records it as a new revision. So let’s say the version of the wiki page with the partially deleted content is version 20, and you revert to version 19 to restore the deleted content. Instead of version 20 disappearing, a new version of the page is created. This new version 21 contains the same contents as version 19, but is a unique version of the page because it was created at a different time, and possibly by a different user. By doing this, the wiki creates an accurate picture of _all_ changes to a wiki page, even deletions and restorations of the page itself.
Wikis let you keep track of changes using email and RSS notification systems. You can subscribe to an email or RSS feed that notifies you when a page has been changed, and gives you a quick snapshot of the changes. As your wiki use grows and you need to keep track of what’s happening on an increasing number of pages, this is an important time saver because it saves you from having to manually check all those pages.
It also allows you to make more timely contributions. Because you’re notified as soon as someone else makes a change to a page, you can edit it or leave comments as soon as you receive notification as opposed to arbitrarily checking the page for changes and possibly contributing a while after the last edit. This helps maintain a frequency of editing that gets a collaborative task done faster and ensures that everyone involved is better informed about the information and the process.
Balancing Trust and Control: Why Wikis Have Succeeded Where Others Have Failed
Wikis shift the social balance away from control and closer to trust. This is a fundamental difference because it democratizes information and collaboration on the principle that greater participation is ultimately better than control, and a fundamentally open system with provisions for control when necessary is better than a fundamentally closed system. There are two reasons for this: the first has to do with technology and the second has to do with people.
From an information architecture standpoint, software that’s designed to impose a high level of control over access and content structure is more complex by design. It has to have the ability to maintain complex structures built into it, and this restricts its flexibility. This can make it difficult or even impossible for it to support a low level of structure, sometimes simply because it’s too difficult for the average user to figure it out! The bottom line is it’s much harder to have an open collaboration environment using a tool that’s fundamentally designed to be closed.
On the other hand, the wiki is designed the opposite way. The simplest configuration of a wiki is for it to be completely open: anyone can read, and anyone can edit. This keeps complexity to a minimum from an architectural standpoint – the software is simpler and less prone to errors since there’s less that can go wrong. It also means the wiki can be used for a wider range of needs, and people can learn how to use it faster so they’re getting to productive uses of it faster than if they were using more complex tools where they have to learn a specific, often complex procedure for each new task.
On top of this lean foundation, enterprise wiki software includes permissioning capability that allows viewing and editing privileges in different spaces in a wiki to be restricted when needed. For instance, on Wikipatterns.com the public site resides in a space where viewing is open to anyone who visits, and editing is open to all registered users. Registration is free, and required because it builds a stronger community where each member is personally accountable for his or her edits because her or his name is associated with them. The home page has slightly different permissions. Anyone can view it, but editing is restricted to just two site administrator accounts, because there isn’t really anything the user would edit on the home page, and we want to maintain a consistent look and feel at the entrance to the wiki.
Besides the public space, there’s a private space in which I’m using to write this book. Using the permission system, I restricted access to just my editor’s account and my own, so that we could work together on the manuscript. As I write each chapter, drafts are immediately available for her to read and leave feedback. She can either edit the page itself and put suggestions or corrections at exact points in the draft, or leave general comments at the bottom of any page. This saves an incredible amount of time because we don’t have to send attachments back and forth by email. When she leaves me suggestions, I can act on them immediately, and she can see the results just as quickly.
Now that we’ve looked at the technical reasons why it’s easier to use a fundamentally open system like a wiki, let’s look at the social reasons. Closed systems implicitly assume that people can’t be trusted and technology has to be relied on to control access to information. This encourages an organizational culture where people don’t trust each other and are concerned with maintaining control over information access. Some people do this because of the perception that with control comes power, and they don’t want to give up that power. Others operate on the perception that they should keep information close to the vest so they’ll be perceived as experts and others will need to come to them for information, thus safeguarding their position. The closed approach creates inefficiency, information redundancy, and reduced focus on common goals because it’s hard for people to know what others are doing so information ends up in restricted silos, and it is difficult to change this behavior once it becomes ingrained.
Fundamentally open tools like the wiki encourage just the opposite. Their design assumes that people can be trusted with the information they have access to, and will use it responsibly to further shared goals. This encourages a culture where people do trust each other, and involve others in their work to build the best possible end product in less time and with less unnecessary back and forth effort. This also reduces redundancy since people can build and collectively maintain shared information sources.
It also does away with that antiquated idea that a person has to hoard information to protect their position and be perceived as an expert. In a wiki-based organizational culture, people are rewarded by how much they actively contribute to the community. Those who share more generally become the thought leaders since their expertise can be tangibly measured their contributions and their approachability. These people become truly indispensable to an organization because not only do they have a wealth of information, but more importantly they’re willing to share it.
The value of information is in direct proportion to the number of people that can use it, and wikis enhance this value by unlocking previously hidden or inaccessible information and giving people the ability to better use it and keep it up to date.
How Atlassian Uses a Wiki to Increase Transparency and Decrease Distance
At Atlassian, we use Confluence – our enterprise wiki – for the company extranet. Every team, product, and project has a wiki space and everyone within the company has access to all spaces. Each person also has a personal wiki space they can use to post a picture, biography, contact information like phone, email, and IM, links to favorite web sites, etc. People also use their personal spaces to blog about progress on various projects, technology and industry developments, useful links, and whatever else they deem worthy. Blog posts are an excellent way to communicate relevant information, spur conversations and debate, and get feedback on ideas, issues, and projects.
This is especially important because the company is spread across three cities on different continents. Atlassian’s headquarters are in Sydney, Australia, and it has offices in San Francisco, California (US), and Kuala Lumpur, Malaysia. With time differences of as much as 17 hours, the wiki makes it possible for a person in the Sydney office to work on a project, update information, or blog about a topic, and people in the San Francisco office can contribute, comment, or collaborate during their working hours, while the person in Sydney is asleep!
Giving all employees the ability to access to all spaces encourages everyone to be as transparent as possible about how they work, and to keep their work well organized so that others can easily find what they need and use it. The time difference makes transparency important because it’s not always possible for a person in one office to just call a person in another office on a moment’s notice. For example, when it’s mid-afternoon in Kuala Lumpur, it’s late at night in San Francisco.
Beyond these reasons why using a wiki is beneficial for a global company like Atlassian, there are some other benefits. When I travelled to the Sydney office for the first time in July 2007, I met a number of people in person for the first time, but I felt like I already knew them from seeing their pictures and biographies in their personal spaces, commenting on their blog posts (and getting their feedback on mine), and collaborating with them on several projects using the wiki.
This is the kind of benefit that’s directly contributing to the more traditional business benefits because it closes the otherwise large organizational, social, and cultural gap that exists when people are halfway around the world from each other. At Atlassian, that gap is minimized by the fact that the wiki is the central hub of activity.
Content management systems have specific, often highly structured and rigid templates for different types of content that users can’t easily changes. A wiki, by contrast, allows you to build the structure that best suits your content. Later on, you can use that structure to create a simple template that can be applied to other pages as they are created.
For example, when I advise a team to use a wiki to manage meeting agendas and minutes, I suggest that they build a basic structure for an agenda page (Figure 3-2) that includes meeting date, attendees, items to address and the name of the person who submitted each item, and anything else they want as part of the agenda.
Figure 3-2 An Example Meeting Template
Once the structure for the page is essentially complete, I show them how to make that structure into a simple template so that each time they add a new page for a meeting they have the option of applying that template. Unlike rigid templates, all the wiki template does is put the basic headings and empty list onto the new page so they just have to fill in the agenda items, date, attendees, and other information. And if they want to change the page after they’ve added the template, they can just remove what they don’t need right from the page.
This kind of flexible, user-generated template system is better than using rigid, pre-created templates because it allows people to go beyond just organizing their information. It enables teams to look at how they work, and make adjustments to be more productive. Best of all, that improved efficiency is the result of a collaborative process, and can actually make people feel more satisfied with the way they spend time.
One team I worked with was having trouble keeping weekly meetings within the planned time, and often had to schedule a second meeting later in each week to cover topics they didn’t get to in the regularly scheduled meeting. To fix this, they decided to use the wiki-based agenda to keep track of how much time they spent on each item during meetings, so they could better plan future meetings. They added a prompt in their template to record the time spent, and looked at which types of topics took up the most time.
Equipped with this information, they now schedule meetings with the most-time intensive topics covered every other week instead of every week, and they also schedule some topics for virtual-only discussion, which takes place right on the wiki page for each meeting. Both of these approaches have resulted in fewer scheduled meetings running over time, and fewer “unscheduled” meetings to deal with the overflow of topics. By using the wiki to manage meetings, they were able to see where time-management was inefficient and improve with a mix of better scheduling and virtually meeting on the wiki. Both approaches ease people’s schedules by eliminating time spent in extra meetings and tapping into the time people already spend online.
Wikis balance simplicity and customization by allowing users to develop plugins to perform specific tasks. This is a smarter approach than trying to make it do everything for everyone and ending up with a tool that doesn’t do anything really well. It’s impossible for a software vendor to please everybody, and it’s not a good business decision to do so, because the vendor should be focused on building an amazing, high quality core product. The challenge for every software maker is prioritizing how it allocates its development resources, and if it tries to please everyone it will be spread too thin, overall quality will suffer, all the custom requests will still take a long time to fulfill, and nobody will be pleased anyway.
Providing the capability to build plugins in lieu of building lots of features allows a more compact, highly focused development team to focus on making a responsive, powerful, scalable core platform. That strong platform provides the basis for a community to build an ecosystem of plugins and added functionality that itself is scalable and can be more comprehensive than if the software maker tried to satisfy everyone. For those using the wiki, the plugin ecosystem is a lot faster and ultimately less expensive than waiting for a software maker to build a new feature, because they can rely on the community to find an existing plugin that meets their needs, or find someone who specializes in building plugins for the software. This keeps wikis simple and reliable at the core, but customizable when necessary to meet specific needs.
Back-office to Front-office
The wiki has risen to mainstream recognition and use in part because it fits very well with some of the key characteristics of the Web 2.0 phenomenon. Like many Web 2.0 tools, it puts more emphasis on intuitive design and usability than a constantly growing feature list. It also aims for the simplest way to perform its main tasks, and social interaction is at the core of how it functions.
Because the first wikis were created to respond to software development needs, they were largely back-office tools from their creation in the mid 1990s to the early part of this decade. Developers use them to track development of their software projects and products, collaboratively write documentation, and quickly share content, such as code snippets. IT staff use them to track projects, document solutions to hardware and software issues, publish online documentation for the tools and services they support, and make information more easily searchable by conducting conversations on the wiki instead of over email.
For this reason, when organizations consider using the wiki as a business tool for the whole enterprise, they often find that they already have a wiki, and their IT staff is already very knowledgeable about the tool itself and how to use a wiki in combination with other tools like email, and traditional content management tools.
Lets look at three examples of how the wiki compares to other tools: email, intranet, and shared drives. The bottom line in each case is that the wiki shouldn’t be a wholesale replacement for these tools, but it does perform specific tasks better than these other tools, and can free the others to be better used for their strengths.
Wiki vs. Email
The primary difference between using a wiki and email for collaboration is in the mechanics of each. If you and I were using email and a text document to collaborate, there’s a lot that would have to happen between when I edit the document and when you can edit it. Once I’m finished editing I have to save changes to the file, then create an email, address it to you, write a message, attach the file and send it. Then you wait for the email to arrive in your inbox, which may happen quickly or take some time depending on circumstances outside either of our control, like network traffic and virus scanning by the email server.
Once you receive the email, you have to open it and download the attachment. Right here there’s the issue of viruses in email attachments. Although I wouldn’t intentionally send you one, there have been so many viruses spread through email that the whole notion of attachments is a touchy issue for people. In fact, many organizations limit what file types you can send as attachments, and some even ban attachments altogether! Once you download it, you have to open it. Let’s hope you have the right software, and version of that software, to open my document. Next to the concern over viruses, this is one of the biggest headaches in collaboration because having the wrong version may mean you can’t open the file at all, and in some cases trying to edit a file with several different versions of a software application can wreak havoc on the document’s formatting. Whew! Finally, after all that mechanical work, you can finally contribute to that document.
But wait! What happens if I send you that document, _then_ get a great idea for something to add? Should I wait until you’ve had time to look over and possibly edit the file to send my new idea? This isn’t so good because my addition may be time sensitive and need to be added at this moment, or it may fundamentally improve the content of the document. If I wait to edit the document until you’ve edited it, I might forget my idea.
So waiting isn’t a good idea. In that case, should I send along an updated version with my new idea?The risk here is that by the time you receive the second document you might have already started editing the first one, and now the progression of content construction has forked into two separate threads, and you’ll have to manually reconcile the two files to make sure your edits get into the file with my most recent edits. If you haven’t started editing yet and have the two documents in your inbox, there’s a risk you might not see the new one, might not know which one to edit and pick at random, or think the new one is just a duplicate email. Here again, you might choose the earlier one by mistake. This results in the same situation where one of us has to reconcile edits between the two documents, and who wants to do that?
If we were using a wiki in that same scenario, almost all the mechanics between when you and I edit the document have been removed, and you are able to see my changes to the document as soon as I save the wiki page. Now if I get that great idea a few minutes after I’ve saved the page, I just click edit, contribute my idea, and as soon as I click “Save” you’ll have the most recent document instantly available.
Keep in mind that I’ve just given the simplest example with only two people. If it can be this difficult for only two people to “collaborate” over email, imagine how these problems can balloon exponentially when there are more people involved! A new wiki user recently told me a story of how it took three days to reconcile the edits that had gotten out of control when twelve people tried to use email to collaborate on a press release. The edits themselves didn’t take that long – within a few hours after the file had been emailed to everyone, twelve distinct files were returned with twelve different sets of edits!
If they had used a wiki, _everything_ would have been done with those few hours. Edits would have taken place on the same “canvas”, and as each person visited the wiki to review the release and add their input, they would have seen the most up-to-date version of the content with the latest edits incorporated. Each time a person edited the page, changes would be based on the current state of the content, instead of the original, unedited state as was the case with each person working in isolation on a separate copy of the emailed document. The wiki could also notify people via email or RSS feed each time the document was changed, which could prompt them to make further changes if they saw an edit and thought to add or edit something further.
In the end, the press release would have taken less time to create and refine, and the process to get to the final product would have better reflected the interaction if these twelve people held an in-person meeting. That’s what makes a wiki so special – it enables the natural patterns of interaction that would previously only be able to happen in a physical meeting – fast-paced discussion, overlapping ideas, quick decisions on changes, quick error correction, introducing different viewpoints and collaboratively working to reach agreement – but it removes the need for everyone to be in the same place at the same time and it documents the interaction better than a traditional meeting could.
What’s Five Minutes Really Worth Anyway?
Let’s say it’s 2:55PM and you have a meeting at 3:00PM. If we were collaborating with email and documents, you might see that message with the attached document and put it off until later because you don’t have time to download and open the attachment, never mind make changes, before that 3:00PM meeting. In this scenario I have to wait longer for your input, and if that meeting lasts a long time, you might not even be able to make changes to document until the next day.
By contrast, if we were using a wiki, you might see the wiki page at 2:55 waiting for your input, and decide to give it a quick read. If you get a great idea, want to make some minor changes, or even just notice a typo, all you have to do is click “Edit”, make some quick changes, click “Save”, and head off to your meeting. Now that the document has your input, collaboration can keep moving forward because I can revise based on your edits, send it on to others for further input, etc.
Because of the wiki, that five minutes between meetings just became much more productive than ever. Now multiply that increase in efficiency by all the press releases, meeting agendas, projects, reports, statistics, sales figures, business processes, and other documents that need this kind of input. Your organization can save hundreds – even thousands – of hours that right now are used inefficiently to reconcile the separate changes made to documents as a result of emailing them. Teams can shorten the time it takes to finish a project or product, which means getting it to market faster and increasing your competitive advantage. People can keep critical documents more up to date, which translates to fewer problems as a result of decisions made based on out of date information or business processes.
That’s the difference a wiki can make for collaboration, and doing this can free up email and help diminish the stigma that’s grown to surround email as a result of peoples’ swelling inboxes. When organizations move collaboration over to the wiki, they reduce the awful congestion that results when a dozen people are copied on an email and most or all of them reply, and return email to its optimal use as a communication tool for more formal messages, and notifications. In fact, one great way to use email is to let a group of people know about the new wiki page you’ve created for collaboration!
Wiki vs. Intranet Powered by Content Management System
The term “intranet” can refer to the internal network within an organization that is accessible only to employees or other authorized users, or the most visible part of that network which is the website people use to access information. The intranet I refer to in this section is the latter, specifically when it is powered by a traditional content management system.
Have you ever used (or tried to use) an intranet and found out that the information you needed was out of date, or just wasn’t there at all? That’s because many intranets are set up with the good intention of providing an internal information source, but are too difficult to update or take too long because people can’t directly update pages and instead have to funnel changes through a designated “gatekeeper”.
Here’s the scenario that often derails intranets: you want to update a page, but you can’t directly edit it yourself. You have to find the person designated to update the intranet, and send your content to them. Since you can’t just make that edit yourself and quickly cross it off your to-do list, you lose that sense of accomplishment. So you put off the task until later, when you have a more significant number of updates, and can feel less like you’re bothering that one overworked person who has to handle everybody’s updates.
The consequence here is that information falls out of date as you wait longer to submit updates. Since that person designated to manage the intranet is often overwhelmed with updates, they are working through a backlog which means that even when you do submit your updates they take a while to appear on the intranet. Because of this, information on the intranet grows stale, and people end up just emailing you when they need more current information.
When intranets are first introduced in organizations, there’s a push to use them, and an initial flurry of activity. This initial popularity, combined with the bottleneck of only a few “gatekeepers” designated to update it, causes the backlog of updates that eventually slows the intranet to a crawl and results in out of date information. Since people can’t just go in and update as needed, the intranet has very little “stickiness” with most employees, so it can’t build the critical mass of users needed to be successful, and this is what causes intranets to fail.
By contrast, a wiki doesn’t have this bottleneck so people can just fix or update something themselves, and they can do it immediately. Direct interaction with the wiki keeps it on peoples’ minds and results in greater participation, which makes it more valuable. Also, since the best way to introduce a wiki is a grassroots approach, people who use it are more intrinsically motivated to do so, and will encourage their peers to do so as well. This builds a social network and support system that helps maintain the wiki’s stickiness with users over a long period of time.
Wiki vs. Shared Drive
The primary differences between using a wiki and using a shared drive for collaboration are access and version tracking. Some teams use shared drives to store files that multiple people need to access and edit, but they’re often only in scattered use throughout organizations because they are not very scalable. The groups that use them successfully often are comprised of tech savvy people who understand the concept of network shared drives, know how to access them, and will put in the manual effort necessary to keep files organized.
But try to spread shared drives beyond these types of groups, and they are hard for the less tech savvy person to use. For the mainstream user, finding the right shared drive on the network can be challenging, which can lead to the scenario where people access the shared drive once, download copies of the files they need, then forget how to or find it difficult to get there again. The consequences here are files on the shared drive fall out of date, and there are numerous local copies of each file on peoples’ computers – all being updated separately.
Even if people do try to keep files on the shared drive up to date, it’s still difficult to manage different versions because it has to be done manually. When someone downloads a file and updates it, they also have to remember to update the file name with a new version number, and if someone forgets to do this, or uses the wrong version number, it can throw off versions for everyone else.
Simultaneous editing also presents a challenge. Let’s say two people download version 15 of a file from the shared drive and update it at the same time. One person finishes first, changes the file name to version 16, and uploads it. What happens if the second person also names their file version 16, uploads it, and accidentally overwrites the version 16 that was just uploaded by the first person? Now changes are lost, and the person who uploaded the first version 16 has to download the second version 16 and add their changes to it.
Confused yet? Me too.
Here’s another scenario: What if the second person who downloaded version 15 of the file and edited it forgets to upload it? Meanwhile, others download, edit and upload the file several times. Now, the local copy of the file on that person’s computer is further and further out of date, which means two things:
# They’re working with out of date information, which may poorly inform decisions.
# Once they realize they’re using an out of date version of the file, they have to work all of their local edits into the shared version of the file _and_ learn all the new information they they’ve missed as the shared file has been updated.
This is where a wiki comes in. Web-based access is a much easier means to find information than hunting through network shared drives. Automatic version control means everyone is working with the most up-to-date version of content, and a notification system when someone else is editing means edits are much less likely to be overwritten.
Eliminating local editing means it’s much easier to see the progression of information growth and change over time. With a shared drive scenario, this would require a lot of manual work to gather lots of different versions of files, but with a wiki versions can be compared side by side on a moment’s notice. Also, notification by email or RSS whenever someone edits a page means other people can keep apprised of changes to the information they use every day, and can make decisions based on the most up-to-date information possible.
This is one of the reasons why most of what’s written about wikis deals with social and organizational issues like appropriate behavior, where and how to use it, and so forth, instead of focusing on technical issues like just simply getting the thing working! Because it’s so simple and intuitive, people are able to use it faster than most other tools. This is a unique phenomenon because the complexity, scope, and steep learning curves of other tools mean that learning about effective use happens much later, often long after people are using the tools in not so effective or efficient ways.
- Cunningham, Ward. “What Is Wiki” http://www.wiki.org/wiki.cgi?WhatIsWiki, 27 June 2002 (Retrieved 25 July 2007).