Developer Documentation: Sharepoint Document Management vs. ScrewTurn Wiki [closed]

Question

Background Info

I am working on setting up a method for my company's developers to share documentation and information about our various internal systems. This would range from information that would be useful for bringing a new employee up to speed, to descriptions of common problems users have with the systems and their resolutions.

This seemed like an ideal job for a wiki to me, and since our company only has the ability to host ASP.NET applications, I set about researching the available ASP.NET wikis. ScrewTurn Wiki seemed to be the most appropriate one, it's very full-featured and there are several plugins available that would be useful for my situation, including syntax highlighting and AD integration.

However, upon starting the process to have ScrewTurn deployed to our intranet, it was suddenly remembered that, hey, Sharepoint 2007 has a wiki, and since we already have Sharepoint set up, couldn't we just use that? I did a bit of evaluation of the Sharepoint "wiki" (in quotes because it barely qualifies), and was able to demonstrate that it wouldn't be suitable due to its many deficiencies, which I won't list here.

Now at this point, it's been suggested that perhaps I don't need a wiki at all, couldn't we just do everything in Word documents and use Sharepoint's document management functionality instead?

The actual question

So what I'm looking for is some additional ammunition, preferably from people with experience. What are examples of things that will be difficult or impossible with Sharepoint in the context of internal developer documentation? What is a wiki better at? Hey, I'm open-minded, what is Sharepoint better at?

What will make it worthwhile to deploy a wiki instead of simply using what we already have?

Answer 1

I'm hoping this is going to be some use - extra points or not :)

SharePoint Server (SPS) or Windows SharePoint Services (WSS) is VERY good if you are working with office documents - you can version, check in/out, share, search etc. I dont think there is anything on the market which comes close for that function (it also does custom lists and stuff really well).

But as you point out, the WIKI function is, well, sub-standard.

For developer documentation, a wiki is much better, as you can easily interlink documents, and even if for the sole reason that developers tend to LIKE the wiki markup! Makes it feel like they are writing code, not a document. Well, ok, I like it. Word documents? endless frustration, especially for code snippits and things like API's. Wikis' usually handle code and structured formatting really, really well.

But here's the main point of me posting:

If you can host ASP.NET - and if you have SPS you can already! - then just install BOTH OF THEM. Make a new IIS virtual host, put STW in that one ('cos SPS will be in it's own virtual host)*. Massage the DNS a bit (so you can hit http://wiki or something), and just go for it.

As it's all internal to your company, and STW has windows security and versions, security isn't a huge issue. Each page can be linked to from anywhere - it's an HTML page after all - so you can link to it from the SPS wiki if you really want to. There is some lock in, I guess, but not a lot.

Here at BBC Worldwide, we use a number of technologies:

• Atlassian Confluence (WIKI) for some projects. I love this wiki, but it IS a big enterprise-y system.
• Screw Turn for some intra-department stuff.
• Trac for some other stuff (someone else set it up with SVN on our source repo, so it's used a little - it's nice, I rather like it, but it's a a*se to setup)
• SPS/WSS for documentation management.

there are links between the STW, Trac and SPS - eg we try not to store docs as attachments in trac, rather link to them in SPS, etc.

Works well.

As for ammo: SPS works well if it fits what you want to do (or YOU can fit what IT does). If not, you are either screwed, or need to do a lot of dev, which is really the same thing :)

But aside from management getting all funny about it, I can't see a problem with installing both. STW is free after all. You have server(s).

And it gets dev's writing docs, which is seldom a bad thing. Ok, it's a bad thing if real humans have to read it, but docs for other dev's? All good.

*note: virtual HOST. Not virtual DIRECTORY.

Answer 2

I've done both. After those experiences, here is my suggestion:

• If you need WYSIWYG and don't care about Sharepoint's bloat and lack of features (the wiki is simplistic, but has the major features you need in a wiki), go with that. It works as a wiki and helps when business people need to hit up the wiki -- lot less time teaching them to use it etc.
• If you can work with barebones and just want a simple wiki thats fast and flexible, you can't beat screwturn.

As for the why to use a wiki, whether screwturn or sharepoint -- it beats word docs in Sharepoint hands down. To use Sharepoint, first off you have to download the doc, edit, upload, or use Office integration which is chancy at best. Wiki's eliminate all the friction and make it dead simple to update. Eliminating friction is key, because when you have to work with word docs you end up just not updating them as often as you should. With a wiki, it's a 2 second pop in/edit/save transaction. With a word doc, it takes minutes to load word, open the doc, edit, worry about formatting, save, etc.