In deploying wiki systems for collaboration environments, it seems like there are three independent feature vectors in operation.
- Wiki Concepts: Edit-any-page concept, modeling navigation (i.e. set of topics, and each topic being wiki word), Simple, directly editable markup.
- Collaboration Concepts: Discussion lists, Document repositories, Contact lists, Tasks, Issues, etc. Portal front end with news aggregated from different lists,
- Text Processing Concepts: Raw text aggregation (creating virtual topics with content included from other topics), creating new content from templates, search, and so on. (Compare these with text processing done on unix systems with tools such as grep, cut etc.)
Sharepoint is strong in Collaboration concepts, but not other two. Its information model is very simple: The site is a list of lists, where each list can be one of: Documents, contacts, tasks, discussion forums and so on. Each of these have predefined schema (but can be changed). A generic 'list' is also available, in which the columns can be created dynamically - each column being of well known type. The home is created using one or more 'web-parts', and each web-part can show content from a specific item of list, or a row of items (with selected columns) from seleted list. Home page (i.e. the central portion of most web sites) is an item - as some row and col in some list. To help navigation, a quick-start navigation bar is available; and a list can be made to be available in it.
Finally, the views are independent of the underlying model, and control the look and feel, accordning to personalization.
So, in sharepoint, if you want to create a page with aggregated content from different lists etc., it is not straightforward. Perhaps we could use sharepoint SDK to do the same, but the fun of using unix-like simple text processing tools is not available.
In contrast, twiki excels in text processing capability (apart from wiki concepts, which is a primary goal.) This is primarily due to its INCLUDE and SEARCH functionalities, which allow it to be used for tasks, FAQs, and even a book. You can visit a set of topics meeting certain criteria, and use regular expressions matching appropriate patterns to collect information. This collected information can be presented in a table. In addition, its plugins provide more involved mechanisms to do text processing - for e.g. spreadsheet functions etc. Twiki has good mix of Wiki and text processing concepts. (And collaboration features are not very well integrated - normally the end users choose the schema.)
But twiki doesn't provide ready-to-use schema for common things such as tasks, issues, contact lists, discussions etc. But in theory, someone can provide plugins to do the same; indeed some such as action tracker are meant for specific tasks. Neverthless, the UI still lags behind. End users expect nice looking interfaces to things like task management or managing a table. Unfortunate thing for twiki is that there is no clear model that can allow third parties to add edit components which employ nice UI. Other new wikis should provide good capabilities for the same.
Each product can grow to fill all the three concepts. Unfortunately we don't find any talk about sharepoint integrating wiki concepts. It will continue to be popular because of good integration with office and other Microsoft components. But wiki could be a disruptive technology. So far Users have evolved from simple email, to using shares, and now using document stores and simple content management to do information management. But weblogs and wikis are new generation of tools for publishing and managing simple content on web. In my opinion, the need of the day is structured information aggregation, deploying common schemas for things like friends and contacts, books, shops, locations and so on: Information that we use everyday. That is dream of semantic web! Can wikis and weblogs fill this need over the time?
