Sharepoint Wikis

Question

Ok, I've seen a few posts that mention a few other posts about not using SP wikis because they suck.

Since we are looking at doing our wiki in SP, I need to know why we shouldn't do it for a group of 6 automation-developers to document the steps in various automated processes and the changes that have to be made from time to time.

Answer 1

I fully concur with the above (Keng). Whatever that thing is within SharePoint (currently using 2010), it is NOT a Wiki by a long shot.

I am implementing an automated documenting solution, where I extract config and other info (like perldoc markup) from source code and XML config files. It inserts the info in a set of DokuWIKI pages, complete with formatting markup (including tables). It comes out perfectly formatted and works with a couple of tens of lines of perl, includes internal links to manually edited static doc pages, and support for namespaces so I can have my information logically organised. There is no way I could do that in SharePoint (sigh - company direction)...

The best I can do is try to make DokuWIKI template resemble sort of the SharePoint site (to keep the look and feel similar) and link out of SharePoint. :-(

Answer 2

Here are some caveats I came across that will vanish if you use a wiki other than Sharepoint.

Sharepoint lets you create tons of separate wikis, but I'd recommend having one big wiki for everything. My company made a bunch of little wikis for each project/feature, but only admins can create the individual wikis, so if I want to write about something that isn't doesn't match one of the predefined categories, I have to find a manager to create the wiki first.

Secondly, if you use Sharepoint make sure everyone on your staff only uses IE, since Firefox doesn't support the WYSIWIG editor. This is a good thing for most wikis, but makes collaborating difficult in Sharepoint. Imagine editing auto-generated HTML in a tiny little box all day.

Third, try to write up your project documentation in the wiki and resist the temptation to upload Word docs to the Sharepoint library. No point in writing up all your docs twice and watching things get more and more out of sync.

Finally, image support in Sharepoint wikis is terrible. You have to add a file to a document library somewhere and type in the URL. My images were forever getting deleted because they don't seem to make much sense out of context.

Answer 3

The Sharepoint Wiki is essentially a list of Static HTML Pages, with the only Wiki-feature being [[article]] links. No Templates, No Categories, nothing.

We ended up having a separate MediaWiki and only use the Sharepoint wiki for text-based content that does not need much layout.

Answer 4

I've played very briefly with SharePoint Wiki Plus. It's a third-party extension that adds features to the SharePoint Wiki. For serious wiki users then you probably need something more than the SharePoint provided Wiki - either via an extension or a dedicated Wiki product.

Answer 5

We run into this topic all the time, and the first question I have taken to asking people is "Why do you need a wiki"? Almost always the answers are things "ease of editing", "multiple contributors", and "Word is to heavyweight". Very rarely have we seen anyone ask for what I consider to be uniquely wiki-like features (special "magic" markup, fine grained version history showing changes, etc). Also, they usually want some kind of categorization of things, not just completely free-form pages.

In the SharePoint world these things should scream "list" at you if you've been working with the tool for a while. There is basically no particular reason to use a wiki for these knowledge base-style applications, especially since "ease of editing" usually directly conflicts with the idea of learning a special markup language for most user. Through a couple of rich-text columns in there, and you're all set. If you really don't like the built-in rich-text editor (yes the image uploading process is clunky and it doesn't work in Firefox), have someone in your organization go drop the 8 Benjamins and go get the RadEditor for SharePoint. It should pretty much handle those concerns.

Generally once we've gotten over the "but it needs to be a wiki" dogma, we've had pretty good customer reception to just using lists. In some cases, where a little more of a page templating facility was required we turned to using the WCM features of MOSS, which requires a little more up-front thought about templates, but also has a better out of the box experience for things like content snippets and image handling.

Answer 6

Before the rant, here is my overall experience with SharePoint as a wiki.

It is a poorly implemented feature that failed becouse there was a fundemental lack of investigation into what current wiki environments provide. That is why it failed in it's editor and why it misses on points like: tagging, history comparison, and poorly generated html code.

You need to skip it and get something else that does the job better and link to it from SharePoint.

Having production experience with both products, I'd recommend ScrewTurn over SharePoint.

see edit history for rant