But the UI sucks.

Oh yeah, and it’s not people focused. Well at least not as people focused as Clearspace. We use Clearspace externally, and through our relationship with Jive also have an enterprise license. So to me it was a no brainer that we’d rollout Clearspace instead of Confluence.

But before that would happen I had to show why the “people” element was important. All the sponsoring group wanted to do was provide a space to collaborate around content. They weren’t considering the serendipitous establishment of weak ties between disconnected employees, and that people connecting around shared interests would boost efficiency at a hard-to-measure macro level.

After several weeks of debating over email we’ve decided to go with Clearspace, to my joy. I’m stoked to start using it with my China team, to find out more about who they are as people, and for them to get a feel for who we are as people too.

The one point that’s hard to drive home, however, is that knowledge will always be federated. During my consulting career and even here I’ve consistently run into people who want to create a single repository that will house all important corporate information assets, and that said repository will be the single place for people to turn to to find information. Such was the impetus behind our original corporate wiki. Although we’re not there yet, I’m starting to convince people that Discovery must be the center point of our Enterprise 2.0 rollout.

In time, I hope.

Stop.

As Dion Hinchliffe says (and as I have written before),

“Discoverability isn’t an after thought , it’s the core”

Organizations need to embrace the fact that their data will be federated. Sure, workers will put their documents in “wiki X”, but they’ll also put them on the file share, in content management systems, and on email servers. Data that cannot be found is useless. Enterprise search will unlock data and increase the propensity for information (and the knowledge workers who create it) to be discovered. Discoverability leads to recognition, and recognition leads to increased participation. Enterprise 2.0 must be approached holistically.

Clearspace doesn’t do this. Thoughtfarmer doesn’t do this. Mindtouch doesn’t do this. There is no “Enterprise 2.0 in a box” solution. Period.

According to the press release, Mindtouch has seen a 100% increase in active installations (200,000 in total) since last year, and is being used by major organizations including FedEx, Microsoft, and EMC (made famous by Chuck Hollis who chronicled EMC’s adoption of Clearspace).

Deki Wiki ships with a nice WYSIWYG editor to make it easy for the technically-challenged user to add and modify content. Moreover, Deki Wiki is a mashup platform and has out of the box integration capabilities with Dapper, Google Charts, widgetbox and Digg, just to name a few services. It can also be customized to integrate with line of business applications, including those that might be exposed by mashup makers like Kapow.

Development Managers will find Deki Wiki’s integration with Subversion and Mantis (an open source issue management tool) to be a big plus.

Aaron Fulkerson is a pretty switched on guy, so I’m expecting Mindtouch to have more and more of an impact on the Enterprise 2.0 market as each quarter passes.

Update: Deki Wiki has had mashup capabilities since June/July 2007. The Dapper extension is new to release 1.8.3.

Read/Write web has just posted about some awesome new features in Mindtouch‘s new release of Deki Wiki, version 1.8.3 (disclosure: I am working with Aaron Fulkerson of Mindtouch on a side project). Deki Wiki is an open source enterprise wiki and can be downloaded and installed behind the firewall. This is a great option for organizations weary of storing their data “in the cloud” as is required by other hosted alternatives.

Version 1.8.3 has some exciting capabilities, namely:

• Support for 9 languages (with two Spanish dialects included)
• Integration to Amazon S3 services for data storage
• Scalability – run 1000s of Deki Wiki instances on a single host
• “Automagic” merge feature when content is edited concurrently
• Easy integration with widgets and apps using Dekiscript and XML descriptors
• Extensions for Dapper and Google services to support the creation of mashups within Deki Wiki pages (this is probably the coolest feature). Extensions are well documented
• Over a dozen new wiki skins

Aaron has put together a video highlighting these new features (check it out here). The most compelling to me is the mashup capability. Dapper is changing the way information is syndicated on the internet, and Deki Wiki has extensions that make it easy to integrate to “dapps” created with Dapper. Data retrieved from dapps can then be fed into Google Charts or Google Maps, for example, to create a rich visual representation of the data.

This could be a game changer in the enterprise wiki market, especially if Mindtouch provides extensions for enterprise mashup makers like Kapow to provide a mashup capability with line of business applications behind the firewall. A partnership there could prove to be very compelling.

I was convinced Versionate would take off because A) they recognized that, at least tactically, collaborative platforms like wikis will have to compliment MS Office to gain user acceptance and B) they were looking into a non-SaaS offering where companies can install Versionate behind the firewall to mitigate data security concerns.

I tried to access the Versionate site to see what they were up to, but the connection timed out.  It could be because of my dodgy internet connection here in the hotel in Mazatlan, however.

Has anybody had experience with their product recently?

evolving extension of the World Wide Web in which web content can be expressed not only in natural language, but also in a format that can be read and used by software agents, thus permitting them to find, share and integrate information more easily.

Indeed the semantic web promises to make entities like “address”, “contact info.”, etc. which appear within unstructured text on web pages, to be machine parsable through the use of microformats. Other semantic web standards, such as OWL, aim to define the relationships between objects and attributes within a pre-determined ontology.

Behind the firewall, an intranet marked up according to these standards would be information Garden of Eden with relationships between knowledge and metadata about content items being deeply embedded. The Discovery process on such an intranet would certainly be very rewarding given this abundance of “information about information”.

All of this works if content is published using the structural components the semantic web requires. And herein lies the problem – structure.

Within the context of Enterprise 2.0 we often talk about wikis and blogs being emergent – meaning they adapt to the needs and requirements of the knowledge worker. We want knowledge workers to impose their own structures, perhaps with minimal guidance through the use of patterns like scaffolding.

So how are we going to enforce the use of, say, microformats every time a knowledge worker writes an address or somebody’s contact information? Personally, I can’t think of a way without imposing structure. And I’d hate to see said structure reduce participation.

I believe in the value proposition of the semantic web, but to maintain current emergence capabilities, wiki and blog technology will have to be significantly enhanced to automatically mark up content when published. I think we’re a long way off from that being possible.

We use Confluence for sharing project information, and it’s amusing to see wiki patterns in action. My project is based in Australia and is staffed with Australians. Yet the other day I noticed an edit to one of our pages by somebody based in Washington D.C. A wiki gnome.

The change was minor, but it made me realize that my project’s activities are visible to and grab the attention of a wider audience across my company. After all, wiki gnomes have to read wiki content before they decide to modify it. So perhaps the presence of wiki gnomes is an indicator that an enterprise wiki is accomplishing its task – diffusing knowledge and connecting people.

While this does not seem overly complicated it, becomes very difficult for users to reuse categories as there’s no feature on the edit page that shows them which categories have already been used. As a result, we might end up with two categories “design” and “designs” that should be the same.

A colleague of mine, Andreas Rindler, has solved this problem with a mediawiki Category Suggest extension.

CategorySuggest provides a Google Suggest like functionality to the edit page of articles. A separate “Categories” input box is added below the article page. When a user starts typing the name of an existing category, the extension retrieves a list of existing categories from the Mediawiki database and suggests matches to the user. The user can either type the name of a new extension or pick from the list of suggested categories.

Click over to his blog post describing the extension for a better overview.

Avenue A Razorfish is now evolving their wiki to include more features. I’d like to direct you to their blog post which contains an embedded slideshare presentation that explains their approach. They’ve definitely got some great ideas.

But the “single instance” approach might be more of a utopian ideal. We often talk about having a bottom up, non-sanctioned approach to Enterprise 2.0 adoption. Bottom up often entails disparate groups creating their own collaboration environments for specific needs, and the result is wiki proliferation. And I’m not sure there’s much corporate IT can do to keep this from happening.

So, pragmatically speaking, it makes sense for the enterprise to embrace wiki federation. This can be accomplished through Enterprise Search. Slap a Google Search Appliance or FAST instance inside the firewall, point it to the federated wikis, and we have discoverability across all collaboration tools. This negates the impetus behind moving the enterprise toward a single collaboration tool instance. Of course the challenge here is to keep the search index up to date with all of the new wikis that popup. But that’s why we have IT guys.

Update: Check out Lisa Hoover’s article for some great insight into Versionate (I’m quoted in the last couple of paragraphs).

Versionate, a new wiki tailored toward the enterprise, has just launched and is getting a lot of coverage. When I read about it I quickly headed over to the site and checked out the screencast. Versionate does a lot of things right, namely:

1. Simple, intuitive, easy to use UI
2. Integrated search capability
3. Strong compatibility with MS Office and other products

And it’s point number 3 that really separates Versionate from the competition. Myself and others within the Enterprise 2.0 community have long held that successful collaboration software must play well with MS Office. Knowledge workers will continue to use Word and Excel for years to come – we cannot expect them to abandon these tools immediately (no matter how hard we try). This means collaboration software must compliment the MS Office offering, and Versionate does just that.

Want to create a wiki page? Upload a Word document. Want to edit a wiki page? Edit it in your browser or in Word or in Open Office Writer etc. Want to revert back to a previous version of a document – version control is included and easy to use.

I can see a few features that Versionate could benefit from, however. These include:

1. The use of tags to compliment its folder-like categorization structure
2. Integrated blogging
3. Richer, facebook-like user profiles
4. A downloadable version (as mentioned on Techcrunch) to mitigate data security concerns as the current version follows the SaaS model

In my opinion Versionate is raising the bar for wiki software. I’d expect to see other wiki vendors following Versionate’s “play with MS Office” example in the near future.