As soon as I mention the word “wiki”, the first thing most
people will think of is Wikipedia. This is hardly surprising,
considering that the site has been one of the ten most visited
sites in the world for some years now. However, this can often
limit our thinking. So when we see that SharePoint offers wiki
functionality, we immediately reduce it to glossaries and knowledge
bases, without seeing the advantages that it can bring us in other
areas.

Since the launch of SharePoint 2007, we have noticed a trend of
organisations using wikis for a number of purposes, the most common
of which being documentation. In this article, we’ll be looking at
the advantages that wikis can bring and then one or two practical
tips on how to use them.

Why use wikis?

Before discovering wikis, we used to write documentation in
Microsoft Word. Word is, of course, an outstanding tool for word
processing (I’m using it to write this article!) but it’s not
always the best choice. Perhaps I’m alone in this, but when I use
Word, I tend to spend more time on formatting the document (making
sure the margins are right, sliding the images to the right places
etc.) than I do on writing the content. Furthermore, my articles
always look different to those written by colleagues and
collaboration is often a nightmare. Either we all get confused by
document versions, or one person takes charge of writing the
document and ends up writing about subjects in which he/she is not
a specialist. Finally, we have the “typo rule”: What happens if you
see a spelling mistake when reading a document on your SharePoint
server? Let’s be honest, most of us won’t update it. We look at it
and say: “I don’t really want to create a whole new version of this
document for the sake of one spelling mistake”.

This psychological barrier is much lower in wikis. Firstly, the
content is split into articles/chapters and not all in one massive
Word file. Secondly, people see Word files as “holy” and won’t
touch them for fear of getting something wrong – especially with
all the warnings “are you absolutely sure that you want to edit
this document?”; whereas wiki articles are much easier to change
and have a large “Edit” button above them to encourage users to do
so. Everyone is an author and a specialist, leading to higher
levels of trust and ownership in the team. Information can be kept
up to date easily and SharePoint notifications easily applied to
keep you informed about any changes. Lastly, the lack of advanced
formatting options (like in Word) saves time and helps boost
uniformity, because it is hard for users to make large changes to
the format.

How to use wikis

In this article, I’ll spare you the step-by-step guide of how to
create a wiki library. Instead, I’ll go through a few questions you
should be asking.

The first is crucial to the success of the wiki: How are you
going to work with permissions? This depends very much on your team
and exactly what you are trying to achieve. Some of our customers
have very open wikis, where everyone in the team can edit
everything. This is great as it is fast and it fosters trust in the
team, but it can be dangerous with more sensitive content. Other
customers have more complex environments, thinking carefully about
exactly who can do what. You may have to create new groups and
manually change permission levels, and also think about whether you
need some sort of workflow. For example, we created a workflow for
one of our customers to change the permissions on an individual
article every time its status was changed. Articles were assigned
to specific authors and only they could see the article until it
was submitted (other authors could then view and edit the article
once it had been approved). This way, we were able to control and
manage the wiki in a very precise way, which is exactly what some
companies require. It is not advisable to use item level
permissions without a workflow, however, as it is very easy to make
mistakes and very hard to administer.

The second question you should ask yourself is how you want to
structure your wiki and where it should be located. Central
knowledge bases are generally best located in their own Enterprise
Wiki site collection, but in most cases, documentation should be
found on the same site as the product or project you are
documenting. This allows you to work effectively with other
collaboration tools, making sure that information is found in
context. When writing the wiki itself, remember to use [[wiki
links]] frequently, as they will help the user navigate around the
documentation quickly. Use headings on wiki pages to help split up
articles into manageable sections, without having to create a new
wiki article for every paragraph.

Advanced Features

Firstly, documentation has to be shared. SharePoint Wikis are
useful when sharing within a team, but if that documentation then
needs to be sent to a customer, then a different format is needed.
The Wiki Extensions provide a PDF export tool for this very reason,
allowing you to save the whole wiki or individual articles as PDF
files. The export format can even be defined using XSLT
technology.

Other features include text snippets, icon galleries and the web
parts, for example for showing documents or links that are relevant
to that article. These can be added automatically to new articles
to ensure that the look & feel of your wiki remains constant.
Our navigation tools are also especially helpful in documentation
scenarios, where a certain amount of structure is desirable.

Conclusion

As you can see, wikis in SharePoint are about much more than
simple knowledge bases. Documentation is one area where you can
really improve efficiency and communication by using wikis: It may
take a short while to get used to the idea, but you’ll start to
reap the rewards soon enough.

If you have any questions about using wikis for documentation or
indeed for any other purposes, then please come over to our stand
at the European SharePoint Conference, where we’d be happy to
help.

Come to the European
SharePoint Conference.