Also, not all the factors below would be relevant in every wiki decision but it won't hurt to go through the list and make sure that you have not ignored some factor that may come to haunt you later.
- Strong WYSIWYG capabilities of the Wiki is essential if you want business users to embrace it. You and your tech-savvy friends may like wiki syntax but business users, in general, don’t like or care for wiki syntax.
- A single huge all-encompassing wiki like “Wikipedia” seldom work in the enterprise - concept of “spaces” or “projects” is almost always required. This also ties back to the "In-the-Flow" usage which I will cover in a later post.
- Granular security with ability to specify permissions even at page level is often a required criterion in enterprise wikis.
- Features like versioning, audit trail, comment moderation are very critical in the enterprise – organizations have different level of sensitivities on what can be published.
- Strong email integration is important for wikis to get adopted. E.g. ability to email a wiki page, comment via email, receive email notifications etc .Email habits die hard and you cannot expect people to switch from email to wikis overnight.
- Strong integration with Word/PDF is very important E.g. ability to save a page as PDF/Word or Import a Word file into a Wiki Page. These are the most widely used desktop editing/reading tools and no enterprise wiki would be successful without seamless integration with these products/formats.
- Seamless integration with corporate LDAP and single-sign on is important in enterprise deployments. From the end-user point of view accessing the wiki should be as painless as possible, to ensure higher adoption.
- Prepare end-users to work in a collaborative environment. If they are putting up content in the wiki they should expect all type of comments and feedback - not all of which may be useful.
- There is no single best practice on how a wiki should be rolled-out within a large organization. But it is best rolled out within those groups/departments that have immediate use for it. Forcing the wiki as a company-wide mandate is usually not a good idea – it can lead to a "Oh-God-Not-another-tool” reaction.
- Let the wiki adoption grow virally. As users within the organization , send out wiki links or email a wiki page, other users automatically get interested or at least get curious to know about wikis.
- Social bookmarking and rating features is very helpful in promoting wikis. Features that show the popularity of pages e.g Most read pages or most commented pages give users a sense of what is being read by users in general. Rating allows users to actually rate articles in the wiki.
- Appreciating the work of wiki contributors by instituting awards like “Contributor of the Week” or “Best Wiki contribution” within the organization go a long way in encouraging users to contribute towards the wiki.
- Best to store content in some standard form like XML or HTML. There is no standard for wiki mark-ups and it is probably not a good idea to have all your corporate content in a specific wiki mark-up.
- Ability to scale up elegantly is paramount for large deployments. Server-side wiki solutions should be scalable via clustering. Open-source solution often fail in this criterion.
- Seamless failover is another technical must-haves for large wiki deployments running on a cluster. Even if wiki applications may not be mission critical, users don’t like to lose content if the application ever goes down.
- The wiki should work on all popular browsers with little or no impact in the functionality. This can become challenging as richer functionality like WYSIWYG, drag-drop etc get introduced into the product. Fact remains that users will be using different browsers, but would expect similar behavior.
- Ability to extend functionality via a robust and flexible plugin framework is important for any Enterprise Wiki. At some point, enterprises always need to integrate their wiki with existing applications and it is best to achieve this integration through APIs/plugins etc instead of a very tight integration.
Posts
