Technical barriers are usually the result of misconceptions about the way that wikis work or are based on reports about early versions of the technology that no longer apply. In some cases, this is analogous to saying you wouldn’t drive a car because you still believe you have to hand-crank the engine to get it started.
Typical technical barriers include the following:
While it is true that early versions of wikis used a simple markup language known as wiki-text, and to complicate matters further, different wikis had their own versions, it is no longer true that you need to learn a markup language to use a wiki.
Nearly every wiki on the market today includes a rich text, word-processor-like, WYSIWYG editing tool. Anyone familiar with popular word processing applications can easily add formatted content to a wiki without ever seeing any markup. Most wikis present the rich text editing interface as the default.
The default search in many early wiki implementations fell short of expectations raised by the almost ubiquitous use of the Google search engine. Most current wikis, however, have either improved their native search engine or have extensions and plug-ins that vastly increase search capabilities.
Plugging the Google search engine into a wiki is also relatively straightforward. As highlighted in Case Study 1: A Wiki-Driven Company, WebWorks.com has integrated the Google search from its website so that searches not only return results from the site, but also from all its public knowledge bases, including the support database, customer project wikis, and documentation wikis.
In an article I wrote on wikis for the ars technica website (Wikis in the workplace: a practical introduction), someone left a comment expressing the opinion that “it’s less about search and more about organizing information.” This is a very astute observation, as the most successful wikis don’t just rely on a search functionality, but also use Web 2.0 technology like tags and user-defined categories to organize information in a way that makes sense to the user community.
Turning on and encouraging such features will result in a wiki where navigation becomes a product of the users’ actual requirements and behavior, rather than the result of a set of guesses by a data designer who’s trying to predict which search terms and keywords will be popular.
Many perceive that while it may be easy to get information into a wiki, it can be difficult to find and extract information. Others contend that a wiki can just degenerate into another file storage area, or download center. Both are symptoms of lack of organization and a failure to define what the role and purpose of the wiki should be.
Just putting a wiki in place is not a solution, because without some sort of direction it can quickly become a dumping ground, and without any oversight information can be lost. But the same could be said of any data storage system. These problems are not specific to wiki technology.
No, wikis aren’t like Microsoft Word, or Sharepoint, or any application you may already be familiar with, because they are designed for different purposes. One of the great strengths of a wiki is that it has many uses, and as such is often compared to existing applications that have been specifically designed to match one or more of those uses. But the essential thing to remember about wikis is that all wikis are based on the idea of an open, readily accessible platform – a web page that allows for collaboration and communication.
The idea of an open, collaborative platform is seen by many as both a threat and a security nightmare. Yet, as I stated above, just because everyone can edit, doesn’t mean that everyone will edit, or that everyone should be allowed to edit. Most wikis have excellent built-in security controls that allow you to restrict access to certain sections, categories, or even individual pages based on personal logins and user group settings. You can easily specify what you want people to see, what you want them to comment on, and what you want them to edit.
A general theme that runs through each of these discussion points is to make sure expectations are set before you implement and start using a wiki. And, remember that a wiki is all about collaboration and communication. Focus on that and not perceived barriers in the tool or the technology.