Wiki-in-the-Box – Is SharePoint Wiki Really that Bad?

Today I’m going to get off the SharePoint Designer shtick, and go back to SharePoint basics. In particular, I want to take a closer look at SharePoint’s built-in wiki functionality.

SharePoint’s wiki has taken a lot of grief online lately. Some people look at various dedicated wiki systems, then at SharePoint, and come to the conclusion that SharePoint’s wiki just doesn’t measure up to the "best of breed". There is a big difference, however, between "not the best" and "totally inadequate".

The Real Question

If you use SharePoint in your company, and are considering whether to purchase a third-party wiki replacement, the question you really need to ask isn’t, "Is SharePoint’s wiki the best there is?", but rather "Will SharePoint’s wiki do the job I need done?"

To help you answer that question, we’ll take a look at what a wiki is, what you might want it to do, and what SharePoint’s Wiki offers "in the box" to answer those needs. I’ll also check out what simple enhancements are available (both within SharePoint, and via add-ons) to extend that built-in functionality.

Just What is a Wiki, Anyway?

Creating pages for the web has historically been a complicated process. It required page creation and editing on a client computer (usually with a specialized tool), and then uploading the finished pages to the web site. Linking required knowing where the target pages were going be relative to the current page.

Wiki-wiki is Hawaiian for "quick". The first wiki was designed to make it quick and easy to create and edit web pages, as well as the links between them. Rather than force users to understand HTML markup, and site structure, a wiki lets them create a link, and if the target page doesn’t exist, it will be created automatically when the link is clicked for the first time. Combined with in-place editing, this effectively makes a wiki a form online content management system.

As noted earlier, a user doesn’t need knowledge of HTML markup to use a wiki. However, because wikis historically have used plain text boxes for entering content, over time conventions have developed for a "wiki markup" for such things as bold and italic text, intra-page section headings, etc… I’ll talk about this in more detail in the next section.

Note: WikiWikiWeb, the software created by Ward Cunningham for that first wiki, used a different syntax from most modern wikis when it comes to links. WikiWikiWeb used compressed text (i.e. Leading-cap words with no spaces between) to indicate text was a link. Current wiki markup convention calls for intra-site links (also known as wiki links) to be defined with [[double square brackets]].

In addition to being quick and simple, there is another, non-technical, aspect to a wiki – something of a "wiki philosophy". This philosophy holds that a wiki should be open to modification by anyone who has something to contribute – even anonymously. Most public wikis hold to this philosophy, however it is not without its problems. For example, while the desired benefit – people with actual knowledge of a subject contributing and correcting inaccurate information – is clearly achieved, it is just as easy for others to post deliberately incorrect information, or even vandalize sites.

While such defacement is just as easily corrected, most modern wiki systems do incorporate certain safeguards – such as authentication, change logs, and approval processes – which can be implemented at need. Indeed, even WikiPedia, the most prominent wiki site on the internet, treats authenticated and anonymous contributions differently, and allows article (page) creators to prevent anonymous edits.

SharePoint Wiki – On the Surface

Now that you know basically what a wiki is, and how they were created to make it easy for non-technical users – and particularly subject matter experts (SMEs) – to create and manage web content, let’s take a look at a SharePoint wiki site.

Note: SharePoint has two things called "wiki". The Wiki Library, and the Wiki Site template. A Wiki Library can be created on almost any SharePoint site, and is accessed through quick-launch just like any other SharePoint list or library. When you create a Wiki Site, a Wiki Library is created in it automatically, the site is set to use the Wiki Library’s home page as its default, and a Wiki Pages section is created in the Quick Launch bar. The behavior of the Wiki Library itself is otherwise identical.

In most respects, a SharePoint Wiki is very similar to any other SharePoint site, as shown below. However, when you look a little closer, you start to see some differences:

1. Wiki Toolbar – The wiki toolbar gives you direct, 1-click access to editing a page, viewing its change history, or discovering what other pages in the wiki link to it.
2. Quick Launch Bar – Notice the Wiki Pages section. This is created in a Wiki Site only. Other "normal" sections (e.g. Lists, Discussions, etc…) are generated as needed if you add them to the site. On non-wiki sites to which a Wiki Library is added, this section is not created automatically.
3. Recent Changes Bar – The Recent Changes bar lists the last five pages that have been updated.

Whether stand-alone, or part of a wiki site, two pages are created by default in a SharePoint wiki library – the Home page (shown above), and "How to use this Wiki" (the text varies slightly to reflect the library or site context). While wikis, by definition, are very easy to use, a quick glance through the "How to" page can still be very helpful. It provides quick tips on the two elements of a SharePoint wiki that are not "obvious", especially to new users – the [[double bracket]] wiki link syntax, and how to create new pages.

To help prevent the creation of orphan pages (those with no incoming links), users are encouraged to grow the site organically, by editing an existing page and adding wiki links. Recall that, if you create a wiki link to a page that doesn’t exist, a new page will be created when that link is first clicked.

Getting Started

The first thing you will probably want to do, is edit the home page to reflect your purpose in creating the wiki site, and create some "seed" links to get your users started.

Notice how I have "set the stage" for my users. I haven’t actually entered any information yet, but by creating these links and a description, I have let people know the purpose of this site. Now, anyone with write permission can click on one of the links with dashed underlines, and they will be able to create content.

Which brings us to the first area of concern in many environments – if "anyone" can go in and modify these pages, what if someone totally messes things up? This is where the page history comes into play. By clicking the History button in the wiki toolbar, I can easily see what changes have been made over time. For example, in the screenshot below, you can easily see the changes I have made to the home page from the default, with added and deleted text highlighted in different colors from that which was unchanged:

 

Because in most environments SharePoint is used with authentication, you will know not only what changes were made, and when, but by whom.

The Editing Experience

One of the complaints often leveled against SharePoint’s wiki is its lack of support for "wiki markup" beyond intra-site page links. While this is true as far as it goes, it doesn’t consider what that markup is designed to do – compensate for the plain-text editing features of most wiki systems. For example, to make italic text in many wiki systems, you enclose the text in ”double apostrophes”. Yet while there are some conventions, there is no true "wiki markup" standard.

Here is an example of the page editing experience in a SharePoint wiki:

Notice that SharePoint’s wiki actually provides a full rich-text editor, with direct toolbar-based access to text formatting, external hyperlinking, etc… The results from these tools are stored as standard HTML markup. This strongly mitigates the need for specialized wiki markup beyond the already included internal linking.

Note: Out of the box, the rich-text editing experience is only provided for users of Internet Explorer. If you have many non-IE users, I strongly suggest that you download and install Telerik’s RadEditor Light. This is a free tool, the use of which is fully supported by Microsoft. I have provided a detailed write-up of it in an earlier blog post. Even if you do use IE, RadEditor Lite provides many other features that are particularly useful in a wiki environment.

Digging Deeper

So, looking at the "wiki" features of SharePoint’s wiki, we see a very easy to use system, which, while it may not offer everything a competitor’s wiki has, isn’t too bad. But the story doesn’t stop there. The other side of the "SharePoint Wiki" equation is SharePoint itself. As a part of SharePoint, the wiki library comes with a number of very useful capabilities, especially around site management.

Much of the "SharePointiness" of the wiki library is suppressed from the default page views. Nevertheless, it is in there, just below the surface. The easiest way to access it is to click the "View All Pages" link in the Recent Changes bar. This brings up a standard SharePoint view of your wiki library:

From here, you have access to all sorts of abilities:

• Setting Alerts to be notified of changes
• Setting the permissions of the library, or even individual pages
• Adding metadata fields – for example, subject tags, or even links to supporting documents
• RSS feeds
• Requiring approval and document check-out for changes.
• Creating different views of the information

In addition, because wiki pages are considered individual files by SharePoint, they have individual URLs, making it easy to provide "friendly" links to users, as well as get detailed usage reports.

Because a wiki page is a "page" in SharePoint, you have a second editing option, under the Site Actions menu. This edits the SharePoint, rather than Wiki aspects of the page, and allows you to add web parts to a page in your wiki. These parts will only appear on that specific page, but can be used for virtually any purpose. For example, here I’ve added a web part that is a view of the wiki library which displays a page preview when you roll over a title:

Content in a SharePoint wiki is also automatically included in SharePoint searches, making it easy to find information even if you don’t know exactly where in the wiki it is.

Conclusion

SharePoint’s wiki features are a bit like Rodney Dangerfield – they "don’t get no respect". Yet, while on their own they may not be best-of-breed in the wiki world, they are still quite useful. In addition, they do something no other wiki system does, they bring the rest of SharePoint, with all of its power and flexibility, along for the ride.

If you are considering deploying a wiki in your company, and you are already using SharePoint, look beyond what a wiki purist might see as perfection, and consider your actual needs. You will probably find that SharePoint’s wiki will fulfill them.