SharePoint 2007 Wiki – not a fan

24 September, 2007. It was a Monday.

This post was originally published here.

Now that I’ve written a couple large-ish wiki entries on our team’s SharePoint 2007 wiki, I can reasonably say I’m not too impressed with the wiki offerings from MOSS 2007. A few complaints so far:

No apparent wiki markup language
No documentation, other than one stock page that comes with the wiki
RSS feed for wiki only covers new items, not modifications to existing items
Only two editing options, WYSIWYG or straight-up HTML
WYSIWYG editor not very efficient and produces ugly, non-compliant, deprecated HTML
No auto-linking, back-linking, free-linking, etc.

Basically, most of the features I had grown to love in FlexWiki are not present. My biggest beef is probably the lack of a wiki markup language. The HTML output by the WYSIWYG is pretty terrible, as it’s mostly deprecated HTML tags like FONT. The whole point of a wiki markup language is to make it easy for non-technical folks to add entries. When using WYSIWYG, styles become corrupted quite fast, as fonts and such are managed at the HTML level.

For example, let’s say you want to have the following entry in a wiki:

Current Build Architecture

Local Builds

Solution-driven builds
IIS vdirs and web site created manually
Packaging steps done manually through a C++ post-build events project
Environment configuration done manually

Server Builds

Project-driven builds
MSI deployment
Custom scheduler service for daily and deployment builds
Uses a NAnt and an MSBuild build script file
Build scripts manually deployed to build server
Build scripts create workspaces, get sources, compile, create MSI’s, and deploy

In MOSS 2007 Wiki, the above structure is possible, but it took a lot of cajoling with the WYSIWIG editor to get it right. I expected the header text to use “Hxxx” html tags, and the HTML produced to look reasonable, so I could fine-tune it. Instead, this is what I got:

<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2></FONT> </DIV>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=3><STRONG>Current Architecture</STRONG></FONT></DIV>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2></FONT> </DIV>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><STRONG><FONT size=2>Local Builds</FONT></STRONG></DIV>
<UL>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Solution-driven builds</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>IIS vdirs and web site created manually</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Packaging steps done manually through a C++ post-build events project</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Environment configuration done manually (i.e., SiteInfo guids)</FONT></DIV></LI></UL>
<P class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2><STRONG>Server Builds</STRONG></FONT></P>
<UL>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Project-driven builds</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>MSI deployment</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Dell Scheduler for daily and deployment builds</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Uses a NAnt and an MSBuild build script file</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Build scripts manually deployed to build server</FONT></DIV></LI>
<LI>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2>Build scripts create workspaces, get sources, compile, create MSI's, and deploy</FONT></DIV></LI></UL>

This is not a joke. Non-XTHML compliant markup in a product released in 2006 is unacceptable at this point. Using deprecated HTML tags like “FONT” is even less acceptable, almost laughable. I can’t even read this markup, it’s giving me a headache.

Here’s the same markup in FlexWiki:

!Current Architecture

!!Local Builds
	* Solution-driven builds
	* IIS vdirs and web site created manually
	* Packaging steps done manually through a C++ post-build events project
	* Environment configuration done manually (i.e., SiteInfo guids)
	* Server Builds

!!Project-driven builds
	* MSI deployment
	* Dell Scheduler for daily and deployment builds
	* Uses a NAnt and an MSBuild build script file
	* Build scripts manually deployed to build server
	* Build scripts create workspaces, get sources, compile, create MSI's, and deploy

Now which markup is more maintainable? Which one is easier to read? Which one is easier to understand, edit, and change?

FlexWiki parses the markup to output HTML, and FlexWiki users don’t have to worry about the HTML, only simple formatting rules. MOSS 2007 wiki is a good first step in a wiki engine for SharePoint, but it’s only a first step. Be aware that its features pale in comparison to the more mature wiki engines, which have been around for many years and many versions.

Wizards and designers are useless to me if the code/markup they generate is not maintainable. Also, why is it that tool consolidation means I have to give up a host of features? Seems that instead of doing a few things well, MOSS 2007 does two dozen things not so well. I’d rather shoot for integration over consolidation and let individual tools shine. Although our CMS/blog/wiki tools are now consolidated on our team/org, I’m not entirely sure what exactly it bought us to lose our superior wiki and blog engines we used previously.

← New favorite deployment method

Organizing with Solution Folders →