Monday, September 24, 2007

SharePoint 2007 Wiki - not a fan

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>&nbsp;</DIV>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=3><STRONG>Current Architecture</STRONG></FONT></DIV>
<DIV class=ExternalClassF7A8AEC3D2A943AE8A574B6CA3D14B2F><FONT size=2></FONT>&nbsp;</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.

6 comments:

TexicanJoe said...

I can't believe that are using deprecated tags! You are right in this day and age Microsoft should be shot for letting this code out the door.

Anonymous said...

We're faced with having to transfer our content from a Docuwiki wiki to a Sharepoint wiki, and we aren't happy, although we've heard vague promises about a Sharepoint plugin which allows use of a proper wiki markup language.

Anonymous said...

Just as i'm searching Google for some resources on how to get MOSS 2007 Wiki to work a little better I find your blog. You hit all my points for going out there to see what else I could do to make it better. Perhaps some day Microsoft will get it right on this one.

Anonymous said...

Good thing I read your blog. Currently, I am reviewing Atlassian Confluence to be integrated to Sharepoint. It has good formatting and used Textile markup, However there are features in confluence that are also present in Sharepoint.

cain said...

thanks for your blog. we're currently looking at creating an internal script repository and was my suggestion to use a wiki with custom form based submission.

senior management has proposed we use MOSS7 wiki support rather than my suggestion of mediawiki, and i'm slightly surprised that there's no wiki markup and pitiful documentation. is this a field in which MS hope to develop?

MJ said...

A wiki without a markup is not a first step, it's a WRONG step.

EASY is the most important for a
markup. Powerful may not be even
second.