Theses are my session notes from the SharePoint Conference 2009:

• Presenters: Gail Giacobbe, Principle Program Management Lead, Microsoft; Ted Pattison, SharePoint MVP, Critical Path Training
• People see wikis as yet another place to store information. They say, "Please don't give me another place!"
• Microsoft used a wiki to enable 400 people to create 15,000 pages of documentation in four months.
• The SharePoint Publishing powers the Enterprise Wiki.
• You can customize the enterprise wiki using SharePoint Designer.
• The relevant content within wikis comes to you through the social networking features of SharePoint's news feed.
• Enterprise wiki: Easy page editing, wiki-linking with auto-complete, cross-brower rich tect editor.
• Features: Page templates (content types & page layouts), Categories (managed metadata), Ratings (web analytics), Tagging and Comments
• Contrary to my earlier understanding, SharePoint 2010 Enterprise Wiki does not include an out of the box table of contents feature. It is something that Microsoft says can be easily customized. (Ugh!)
• The enterprise wiki is designed to be customized and scalable.
• Anything available within SharePoint is easily integrated into the enterprise wiki.
• Leverage SharePoint's compliance (policy, records management) and content management (workflow, approval) capabilities within the wiki.
• You can easily integrate web parts into a wiki page.
• Edit in place, live preview
• Support for "reusable content"
• Insert images and media files directly from your computer. You do not need to upload them to a SharePoint library first.
• When you start a link by typing "[[", a list of all the existing wiki links appear, so you can quickly select the one you want or create a new one.
• The My Site news feed is a critical part of the power of the enterprise wiki, since that is where you are notified of new relevant content and activity of the wikis you visit. (I wonder how you control being inundated with news feed items when you are associated with a very busy enterprise wiki.)
• Working with CSS is "much easier" than it was in SharePoint 2007.
  

A little more than a year ago we learned that people in our company were standing up wiki solutions on their own because IT did not have a wiki standard. At that point we identified three wikis, all built on a different open source platforms, including OpenWiki, MediaWiki, and Flexwiki. Clearly we missed the opportunity to anticipate demand. However, it wasn't too late to limit our risk.

In less than two months we identified stakeholders, gathered requirements, evaluated wiki solutions, and selected a standard. The goal of the standard was to prevent (at least going forward) the proliferation of disparate wiki platforms. We selected Screwturn Wiki because it was open source, built on Microsoft .Net and SQL Server, and met our functional requirements. However, due to our need to establish the standard quickly we did not have time to operationalize it. This meant that there was no centralized infrastructure, no internal support team, and no guidance on how to implement a Screwturn wiki to work well within our company. Development teams were basically on their own to build and support their Screwturn wiki instance.

While the Screwturn wiki standard met our goal of building new wikis on the same platform, the way we implemented the standard did not meeting the needs of our end-users. They wanted a standard that was fully supported by IT and on a centralized infrastructure. Self-provisioning of wiki sites was also an important requirement. They didn't want to engage IT people to create a wiki. They wanted to simply push the "new wiki" button.

As all of this was going on, we were in the process of implementing Microsoft Office Sharepoint Server (MOSS) 2007. We had heard that MOSS included its own wiki out-of-the-box. This was intriguing to us since it would mean that we could leverage our MOSS infrastructure and support structure. It also would meet the self-provisioning requirement. However, we immediately learned that the MOSS wiki is a really a WINO: Wiki In Name Only

The out-of-the-box MOSS wiki lacked many features that had become standard in today's open source wikis, including table of contents, sections, sectional editing, and intra-page linking. This perplexed us. It was as if Microsoft had thrown their "wiki" into MOSS at the last minute so that they could check the wiki box on the feature comparison chart. While the MOSS wiki may have some value for people who had never used a wiki before, those who had find it utterly lacking.

So, we had a problem. Do we try to use the MOSS wiki for the masses and allow people that need a real wiki to continue to use Screwturn? This would require us to address the operational shortcomings of our Screwturn standard, which would take time and money. It would mean that we would need to operate and maintain two separate wiki solutions, which is complex and redundant. We needed a better solution

Our research revealed very few full-feature wikis built on MOSS. In fact, we only found three possibilities: Kwizcom WikiPlus, Community Kit for SharePoint (CKS) from Codeplex, and WikiPoint by Neoworks. We ended up dropping the CKS from consideration because it lacked sectional editing and intra-page links. We also eliminated WikiPoint because it appeared to only be supported on WSS 2.0. That left WikiPlus. If that didn't work, we were prepared to do what was necessary to operationalize Screwturn wiki.

Our initial evaluation of WikiPlus was not great. While they did add a few interesting features, such as reporting, lifecycle management, and an enhanced editor, they were missing critical features, such as a table of contents. We contacted them and learned of a new release that would not only include a table of contents, but sectional editing and intra-page links. Over the next several weeks we worked closely with Kwizcom to address our unmet requirements. They were very responsive to our needs. The result was a feature-rich wiki solution built on MOSS. Our people who evaluated WikiPlus liked it better than Screwturn, primarily due to the WYSIWYG editor.

Someday Microsoft's wiki may grow up and eliminate the need for a 3rd party solution like Kwizcom WikiPlus. Until then, its nice to know there's a viable alternative.

Ray Sim's Learning Connections blog posted one of the best wiki use case lists I've seen. In addition to those on Ray's list, I thought of a couple more. I came away from the exercise with the sense that it is possible to do almost anything in a wiki, whether it was the best tool or not. It goes back to the idea that if there's nothing in your toolbox other than a hammer, then you'll try to fix everything with a hammer. That being said, I think the following list has some creative and interesting use cases:

• The Wikipedia use case: "community creates consensus-based truth regarding a particular topic."
• Documenting a business process (step by step instructions) — either as an initial draft for what is later to be "locked-down" in a document form (e.g. as required by government regulations), or not.
• Sharing tips and personal experiences related to a business process that is documented elsewhere.
• Creating a Frequently Asked Questions (FAQ) to support a software application or business process.
• Creating a glossary of terms that are specific to the project or company.
• Creating a "portal" to commonly used resources within a team or community, e.g. frequently used URLs to applications, documentation, contact information, etc.
• Creating a bibliography of team/community member's reading that they found valuable for the project or topic.
• Preparing for a face-to-face or virtual event. Gathering participant input (e.g. proposing and finalizing agenda topics) and defining logistics for the event (e.g. when participants flights land, arranging car-pooling to the venue, selecting dinner locations, etc.)
• Supporting weekly (or other periodic) face-to-face meetings. For example, conference room(s), phone numbers, facilitation assignments, agenda, minutes, etc.
• Augmenting live conversation, e.g. taking jointly visible notes during a virtual meeting — either as part of a web conferencing solution, or independently.
• Maintaining a "lab or project notebook" to share across shifts (teams working different hours on the same project) and/or physical locations.
• Collaborative writing - For example, user documentation, proposals, policies, etc.
• Collaborating on product or solution development including design, features, and technical specifications.
• Disaster management site – Real-time communication and coordination of recovery efforts.
• Strategic Marketing / Competitor Information - Document marketing strategies, results of market research and comprehensive information and analyses of competitors and link them to supplementary information – before, during and after the product launch.
• Knowledge-base or support site – support questions, issues, solutions, how-to guides. comprehensive documentation of so-called ad hoc expertise to assemble a network of unstructured knowledge, for example, of specialist knowledge about corporate processes, guidelines, recurring organizational processes, checklists, etc.

Let me know your thoughts on these use cases and if you've encountered others.