So, after hyping Sharepoint Wiki to a customer, I went about trying to put one together... only to find that there are some bizarre limitations to contend with.  To my mind, the idea of a Wiki in business is a good one.  For example, moving my company's employee manual from its monolithic FrontPage site to a Wiki.  This is how I sold it to my boss:

-------------------------------------- 

With FrontPage, you’d need to know this path to get to the Conflicts of Interest page:

http://intranet/policesandprocedures/section1/general/conflict_intrst.htm

With a Wiki, all you need to do is type [[Conflicts of Interest]] and the hyperlink is automatically created.

That said, there are a lot of advantages to a Wiki:

1.       Wikis are easy to update.  You don’t need a special editor to open and add content.  You have an Enhanced Rich Text Editor that can do advanced formatting, pictures, etc.

2.       SharePoint Search fully indexes each Wiki page; you can also provide keywords to increase search accuracy.

3.       There is detailed versioning, content approval, and workflow tied to every change you make to a Wiki page.

-------------------------------------- 

So... an easy sell, right?  Sure!  But the thing is, a Wiki isn't a good fit for everything.  When you need to step outside the box and customize the generic Wiki form, you find that a Wiki page isn't a content type.  You don't get to upload your own templates.  It turns out that a Wiki library is a list, and each Wiki page is actually a field with rich text formatting. 

 So the lesson I learned today is that Sharepoint Wikis are only somewhat cool.  The limitations I've discovered are:

1. The problem I discuss below with RTF fields
2. Since the body of a Wiki is actually just a RTF field, you can't do any bookmarking.
3. You can't specify your own template for a Wiki page, for example, to put a number of default sections or a table for laying out sections.

Of course, I could always use Sharepoint Designer and compose my own pages, but then we're back to the ease-of-updating issue.  The one selling point is that authors could easily update content without having to know HTML or using fancy tools.

For my project today, I was trying to customize a Wiki so that it had a number of additional fields.  The customer desired a documentation methodology for the many databases and automated processes in production.  I'd been handed the criteria that each page had to have sections such as Overview, Installation, Maintenance, etc.  Some sections are optional, some mandatory, some would look up data from other lists. I wanted to use multiple rich text fields, so that it would display nicely when viewed online.  However, this is wierd: a Wiki page doesn't allow additional Multiline fields with Rich Text formatting enabled (they are forced to plaintext). 

I played around with Microsoft's Knowledge Base template, which actually is a bit more useful than the standard Wiki library.  But since it also inherits from the Wiki type, it also prevents multiple rich text fields.  Also, strangely enough, even though it inherits from Wiki, you lose the ability to use [[double brackets]] for quick linking. 

So I created a Custom List and reverse-engineered the Knowledge Base library, using the same Keyword and Related Articles lists.  The Custom List allows you to use as many RTF fields as you want.  However, each field is locked for width, so it doesn't look as pretty as a Wiki page.  Naturally the customer asked if I could make the fields wider.  I couldn't.

Finally, I ended up playing with Infopath 2007.  Infopath has always intrigued me, but the 2003 version was confusing to use and none of my customers wanted to use it, so I never got to use it in any projects.  With Infopath 2007, though, I finally had a way to design forms and deploy them to HTML.  What I ended up doing was creating a form in Infopath, with nice big fonts and colors, and deploying it to my Sharepoint site, where it rendered perfectly as a webform.  This way I got to specify the interface and still collect all the data I needed. 

I was lucky enough to have a customer running the Enterprise version of Sharepoint. Only MOSS 2007 Enterprise allows you to use Forms Server.  (Actually, there is a stand-alone version of Forms Server sold on a seperate SKU.  It is basically just WSS with Forms Server turned on.) 

Anyway, my Googling today revealed a lot of people who also think Sharepoint Wikis are only somewhat cool.  There is a project over at CodePlex.com to develop an Enhanced Wiki for Sharepoint 2007.  It's still in Beta, but I tried it out anyway and it works pretty well.  It didn't solve my problem today, but it does make the feature more useful in that it adds the ability to attach discussions to each Wiki page, and allows standard Wiki markup.

I also found a post from Michael Hofer, who appears to have solved the problem with putting in your own Wiki content types.  I haven't tried it yet, but it looks promising. His solution involves C# code, modifications to the GAC, and editing of the CreateWebPage.aspx file.  

You will notice, in my posts, that I tend to avoid programmatic solutions.  I have a lot of developer experience, but I prefer to use customization techniques before diving into code.  Custom code is time-consuming to develop and a headache to maintain and support.  It's also really easy to go off into the weeds and waste a lot of the customer's money.  I always leave SD options on the table, but I don't hype it.