Thoughts on Structured/Unstructured and Shared Information Management
using Wiki and other emerging technologies
Providing (multi-dimensional) Tab-based views on wiki topics
Wiki systems allow you to store a lot of information in single editable topic (page). Sometimes this information can be mapped to headings and subheadings (like in article), and some other times we can use large tables. The model doesn't disconnect the store from data views. We can, in theory, use CSS and Javascript to effectively create views on selected information. But the idea is to also create some kind of standardized models so all wiki's can implement them.
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.
[Mishoo] Me, myself and free software
[Mishoo] Me, myself and free software (old article) - interesting read about frustrations of a free software developer; and others' responses to it - some of them giving how it benefitted them eventually (primarily through brand recognition).
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.
New Directions for Knowledge Management Software | DM Review | Industry Led, Industry Read is a good (but 1999) article on how the focus is shifting on two lines: (1) From document-centric KM to people-centric KM (2) Manual to automatic content categorization.
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.
-Vinod
Single-button publishing to portals using Wiki
One of the main reasons that makes blogging so popular is the process of publishing: A quick "single button" with help of tools such as blogthis.
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!
beyond bullets: A blog by powerpoint expert (on powerpoint!)
By Cliff Atkinson. Here..
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.
A good article on Knowledge Management use cases DenverPost.com - BUSINESS - including a use-case from Sun engineers who created a system to allow employees to contribute new ideas (with 'quick jotting down' as key focus.)
BlogThis from within a wiki system: Enhanced threading and categorization across blogs?
We normally see that wiki systems have some "active" users who do the editing, while most others only read the contents; and are afraid to contribute because they are afraid to edit the topic (for lack of wiki markup knowledge). They will more easily contribute in the comments area immediately below the topic.
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!
Automatic Categorization Tool for Open Software Repositories (Shinji Kawaguchi of Makoto Matsushita, Pankaj K. Garg of Zee Source, USA and others) gives a good overview of technologies as applied to software collections.
