The following post is the 2nd part of a continuing discussion of wikis in SharePoint.

Addressing previous concerns

In Dion Hinchcliffe’s article “SharePoint and Enterprise 2.0: The good, the bad, and the ugly,” he highlights 5 primary issues with SharePoint 2007 as an Enterprise 2.0 platform, specific to wikis. Here we will examine how those same issues fare in SharePoint 2010.

“SharePoint is not a Web 2.0 native.”

The author references the fact that SharePoint 2007 was designed before the Web 2.0 movement really took off, and before users had a good understanding of which features make social networking sites the most valuable. He specifically cites that SharePoint 2007 is “particularly weak around critical capabilities such as encouraging emergence, being freeform enough, and support tagging well.”

As we discussed, tagging is now fully supported in SharePoint 2010, not just in wikis but in all content in SharePoint and even external links. Hinchcliffe cites this feature as being the most important out of the three.

With regard to “encouraging emergence,” both the tagging feature and the liking feature allow users to determine which wiki articles have value, hence allowing the most valuable of the articles to emerge organically.

The last issue, “being freeform,” is certainly an improvement in SharePoint 2010. The new wikis allow you to set layouts (i.e. columns, headers, and footers) and allows you to insert pictures, documents, and even web parts, but compared to some of the more common wiki platforms such as MediaWiki, it is still lacking in some functions. Most notably missing is the ability to easily create a table of contents for the wiki article and configuring navigation specific to navigating the wiki, not the entire SharePoint site.

“The technology landscape of the enterprise environment fits SharePoint well; the business requirements to a lesser extent.”

This issue relates not just to SharePoint but the general Enterprise IT paradigm as a whole that promotes multi-level security, governance, and policy controls. According to Hinchcliffe, the benefits of Enterprise 2.0 are best realized when information is accessible in a simple flat structure connected by links, similar to the web, rather than a complex landscape of legacy systems, silos, and applications as it is in most enterprise environments.

Unfortunately, this issue still persists in SharePoint 2010, and is likely to persist in future versions as this is a general requirement of SharePoint as a document management system and not an Enterprise 2.0 platform. Still, it seems there are ways this could be mitigated, as we will explore later on.

“The wilds of the open network can be a challenge for SharePoint.”

Here the author highlights SharePoint 2007’s lack of support for browsers outside of Internet Explorer on a Windows platform as being a detriment to user adoption. SharePoint 2010, however, has elevated Firefox (on Windows machines) to a Tier 1 supported browser, making it equal in SharePoint’s eyes to Internet Explorer. In addition, Safari and Firefox on non-Windows machines have been elevated to Tier 2 supported browsers, meaning that they feature an increased level of compatibility.

While an ideal 2.0 solution might be completely browser-agnostic, this is very much a step in the right direction.

“Self-service capabilities are lacking or not emphasized.”

According to Hinchcliffe, SharePoint 2007 trades off end-user control for manageability. He states, “The more cookie-cutter SharePoint installations are, the easier they are to manage but the more they unnaturally constrain their use and prevent desireable outcomes.”

Once again, we enter into a battle between “SharePoint: the Enterprise 2.0 platform” vs. “SharePoint: the Document Management solution.” While it is unlikely that full control of site creation will ever be given to the end-user (in fact, many SharePoint installations already deal with IT manageability issues of having too many user-generated sites), SharePoint 2010 boasts increased flexibility in design, not just in wiki pages as previously mentioned, but in any SharePoint page design as well. For example, web parts no longer need to be associated to a zone, but instead can be dropped in anywhere on the page.

Whether or not this added functionality is enough to realize more of the gains Hinchcliffe talks about remains to be seen, and is still dependent on the individual organization’s IT policy.