Tabs provide one such paradigm. (For example, see article Classic System Solutions | Articles. Each block (i.e. a section) can be put in a DIV tab, and its visibility property can be mapped to the tab. (i.e. make it visible only when tab is clicked). )
If there are more than one dimensions, then usually tabs are not good. (See the above article for more information). You would use tabs for first dimension, and then some other scheme - say a series of links - for second dimension. I still like tabs for multiple dimensions (at least two dimensions!) - no one seems to have created a scheme I have in mind: Create the set of tabs arranged as series of rows; one behind the other. Let first column select the row first (i.e. it will change the row color). And then select column. Don't bring the selected tab (row/column) to the front line; it is highly unuseable. The mental models typically want information to be attached to spacial positions, and would want it to be as static as possible.
Whether we use tabs or whatever, I hope to see some designs based on the main theme: Allow multiple views on the same topic information, using standardized mechanisms that can be used by any wiki system.
One important observation: Eventually solutions are important, and not software. Enterprises will not take the trouble of creating their own solutions; they would like solution providers to give them solutions. It is this community that should (and would) sustain the free software developers - through support contracts, contibuting for features etc. Eventually it is the group dynamics i.e. everyone's value within a group is quite less, but the value of the group is very high.
A nice graphic is presented to show the trend on three lines: (1) Search leading to text mining, automatic topic creation catalogs and visualization, (2) Document management which will integrate user profiles (of interested categories) and automatic catalog visualization (3) email integration evolving to collaborative environments such as communities of practice, collab filtering, and so on.
Perhaps the important part of this experience is that you know how and where exactly content is going to be made visible: At the top of the page. This doesn't seem important. But when you see this in context of wiki's where "where you put content" is not so obvious unless you navigate till the destination. And if you are maintaining page such as FAQ, then it is another level of "decision making".
But seen from different context, it seems to me that wiki's can fill in a requirement which so far has been a difficult process: Publishing information on intranet portals (containing announcements, key links and so on).
The idea is to create mechanisms that will generate content on portals with single "publish this to portal" button embedded within the wiki topics. For example, if you have "FAQ of the Day" published on the portal page, then have a 'publish this' button in your wiki where you are managing all the FAQs. Similarly, if a particular department is managing their announcements on long term basis, it makes sense to manage these within a wiki, and have a "publish this" button that pushes selected information to portal.
So, we have wiki to manage various contexts (especially when you are part of group), comments and personal thoughts go to your blogs (ref to my last blog on this), and "publish this" completes the picture for public consumption via portals.
Let us hope wiki authors implement this capabaility and do to portals what blogs did to individual publishing!
Good amount of information, such as the following in one of the posts:
What do GE, Cisco, Apple and HP have in common? If you drew a blank, that’s exactly the right answer. That's because they're among a group of visionary companies that have chosen white as the background color of their corporate PowerPoint template.
So why is that we don't have buttons such as "BlogThis" (i.e. add your comments), "View all comments" buttons below wiki topics, but these aggregate information from blogs and provide a threaded view? Essentially, a well-integrated "blog-this" approach that allows users to comment on articles and wiki topics. Main area of such a wiki would be organized information - in form of a well laid out document, tables, checklists, tasks etc., and not really involving comments.
The interesting part is the granularity of where you can seek comments in topic. Usually you seek comments at the end of the topic. But in this model, you can place a number of "BlogThis" icons anywhere in the topic. For example, one for every task defined. How to interleave comments (dynamically read and cached from all the blogs, retaining the threaded structure) is upto the UI of the wiki interface. Usually this can be a a #ref to a (automatically generated) comments section at the bottom of the topic.
This integration can also make sure that (1) Categories are automatically added - possibly from dmoz and, (2) Timestamp is provided, which can roughly be used to order the comments. (3) Template for things like votes and form fills.
Within an organization, this has very interesting implication: Users can have a blog without realizing they have one! (Since they never need to use standard blog interface). Votes and form-fills can be integrated with RSS blogs in much simpler manner. Of course, existing blog interfaces will need to be enhanced for this.
I am thrilled! A good mechanism to reduce email overload using blogs!