wiki-thoughts

Compound Documents for the web

2006-10-26T18:45:00.000+05:30

John Udell recently highlighted the problem of Compound documents for the web:

An HTML Slidy presentation is a collection of files: a single main XHTML file, a JavaScript file, one or more CSS files, and one or more media files which can be images and, in my case, sometimes also movies. It runs identically from a local disk using the file: protocol and from the web using HTTP. But for an event, the host usually wants to receive your presentation and load it onto their machine. And the zip-transfer-unzip dance is more friction than anyone needs or wants.

Among the solutions proposed, either use RFC 2557 approach of including everything in single page (like a MIME message, but not quite so); or to use a zip/jar file to download and manage those files. Both of them are inadequate and not so web-friendly.

I think we should adopt ATOM standard for this purpose. Firstly, APP protocol (which manipulates ATOM resources) can be used to identify and manipulate individual resources/entries. Second, an atom feed is a single XML document that can contain multiple entries. Though this approach has been used to store feed entries, it is possible to come out with a simple approach where first entry has some sort of list of entries, and the rest of entries are in essence media entries, containing the inline data. All we then need is a good support (like javascript ATOM library) to extract/reference any specific content. In particular, we require a server side mechanism such that just placing this feed as a file on server will enable APP protocol capabilities to manipulate the contents and reference media entries as direct web resources.

The key reason why we should do it is: We just want a linear set of resources in a collection, and not a recursive structure (as in MIME).

BarCampPune ...

2006-06-17T15:33:00.000+05:30

Finally BarCampPune is here and happening in Pune (courtesy Symphony for having given the facilities, sponsoring lunch etc.).

I presented my efforts in Structured Wiki area (Flexischema framework in twiki). If you are interested, please contact me - especially if you are good in perl.

(Some more, non-wiki blog postings in my other blog - Metavibes.

2006-06-15T15:46:00.000+05:30

Great article in collaboration loop - by Steven Tedjamulia, Knowledge manager at Novel: Collaboration Loop - How Knowledge Workers Would Like to Work. The key points summarized from their internal survey of about 80 people:
- Standardized collaboration system that integrates tasks/emails/events etc. among all their interactions (i.e. with co-workers, customers etc.)
- Teams should be able to do content management and share information effectively
- Be able to set up collaborative workflows themselves (and not by IT dept). And that too with other information sources such as SAP!
- Be able to get to right experts.
- One search engine.
- Contextually identify the importance of document.
- User portals - where they can integrate different data themselves.
- Integration with presence information, for better simulation of face-to-face interactions (since, the whole purpose of collaborative systems is to be able to achieve good collaboration even when people are not in same room!)

In my own experience, this KM+Collaboration stack should use commonly understood paradigms. For e.g. to point out a good resource to a friend, you simply send the URL of that resource by email. But the problem is, this information remains in email. We need a way that will allow this person to integrate that information back into his own view of the same underlying collaborative world. (In any case, email integration remains a big issue in these scheme of things.)

Current recommendation for this type of stack:
- Wiki for uniform collaboration as well as document management (by having a topic for each submitted document. Use the same approach to convert a submitted mail into a topic. (Mails need to be shared this way - by forwarding to shared areas's email - so that it becomes public information in controlled manner.)
- The above wiki supported by good Search mechanisms.
- Tagging framework for subscription, ranking etc. Further the tagging framework (like delicious) needs to be uniform across intranet, extranet and internet resources. By using wiki, each resource would have unique URL, so this is indeed possible.
- User portals as extension to wiki. Have special plugins/macros to allow user to reconfigure how the page contents should look like. These plugins pull data from different sources. For e.g. twiki has plugins to display RSS feeds in any topic.
- Everyone uses wiki based collaboration as uniform approach. Team areas can be easily created in these wiki systems.
- RSS feeds off wiki to ensure easy consumption of information.
- We also require a mechanism (as part of collaborative areas) to reference other resources and organize these references in nice way.
- Expert location is very easy when everyone uses tagging infrastructure.
- Some Wiki systems allow workflows to be created by end users.

What's missing? I would of course like to see good email integration; especially for workflows. Usability is another area of importance, and wiki systems aren't exactly known for their usability (i.e. end users has to learn a lot.) Lot of ajaxy constructs are required (and usable by process owner) to create good processes within wiki frameworks.

We do keep experimenting with these approaches (-- in my day work, as being responsible for good KM implementations). Some aspects are easy, but some are cultural and still evolving...

BarCampMumbai - May 13th

2006-05-12T09:42:00.000+05:30

It is very nice that BarCamps are providing a platform for Indian geeks.

I would be there in Mumbai for this event (at IITB, Powai), and I am interested in discussing in several emerging areas: Dynamic applications (i.e. which are created on the fly by business users), Wiki Systems (and our enterprise deployment experience), Structured Wiki (and some demos) and so on.

So do get in touch! (I work in Pune.)

-Vinod

Increasing the responsiveness email programs on desktop ...

2005-12-09T16:07:00.000+05:30

As I type this, I am waiting for my thunderbird to refresh itself and help me see latest emails from our corporate IMAP server. This is a routine affair: As soon as I open the laptop, most of the hibernated program would have to get loaded into memory, and that often takes a long time. Sometimes as long as 10 minutes.

So what do I do? Resort to web-based email access which our corporate server provides. This seems to work because Firefox seems to consume less memory, and is "more responsive" compared to Thunderbird. Also, the issue could be with thunderbird having to initialize a large email store (I have anywhere between 3000 to 4000 emails in inbox at any time). The headers are synchronized first, and are available instantly. But the loading the body takes a lot of time.

So here is the idea: Enhance thinderbird extension so that it helps open email using browser - assuming that your webmail can take the URL with appropriate ID, and allows you to login without losing that ID...

Small niceties always help.

-Vinod

Future of template languages?

2005-12-07T19:47:00.000+05:30

It seems like the templating mechanisms will continue to evolve. I came with some requirements and will watch how they will play out in future.

We need Javascript as well as Server side templates. Trimpath folks have a templating mechanism for javascript. Their javascript-equivalent of Ruby-on-rails has a good comparison of ruby template with their own templates (RubyRails Vs JavaScriptJunction ). One of good things this engine is the fact that it can be used both on server side (using Rhino) and client side. But my point is different: The same template should be rendered both on server side as well as client side. And that means some things are resolved by server, and some are rendered at client side. So how do we decide how to partition? For e.g. Layout is server side, but the contents in each boxes are necessarily driven by ajax. This in turn require JSON-RPC integration with underlying template mechanism. The objects used within the template need to be added to JSON-RPC bridge automatically. I should be able to simply add "remotehost=xyz.com" as one of the attribute to where the template is hosted, so the client-side template has access to server-side objects using JSON-RPC bridge seamlessly.

As the app devel cycle takes lesser and lesser time, the UI improvements will keep going on continuously. A simple "merge" operation should be sufficient to ensure that the developer-made changes are automatically integrated into next version of UI. This means templates should be designer-friendly and amenable to versioning, diff's and merges. This means that all the "code" part to be within attributes and special tags. Kid template language of Python does this right.

And again, assuming we spend time with UI, we require templates to be managed by content management system - and that means Wiki. And more important, we would like the capability to be uniformly available to end users as well. And this means we need to have "Safe" templates - those which can be edited from web itself. For example, Liquid, a ruby-based templating system, seems to do it.

Widget integration is going to be another interesting area. Dojo, prototype etc. already give us good widget environments. Widgets will probably make it easy to standardize on Layouts - such as 3-column, or 3-pane (like in outlook). How exactly should widgets get integrated with templating languages? In some sense, widgets seem to compete with standard templating approaches: A widget specificaiton is going to be very simple. Remember Dojo's ridiculously simple slideshow widget example specification? And the problem is, the widget is going to take inputs as parameters. Some of them will, well, be widgets. And this means that your template will basically be XML tree, and that's bad. (After all, templates should look like real HTML!) In any case, as long as browser can show this properly without requiring other servers, I think people will come to accept this approach. We would have to see how this will roll out. And not to forget, we are also talking of ajax-enabled widgets which need to integrate well with JSON-RPC or some such scheme.

In any case, javascript is going to be an important ingredient.

-Vinod

Structured Blogging vs. Google Base

2005-11-18T09:21:00.000+05:30

The post from Niki Scevak
- Open letter to Google Base Product Manager highlights Structured Blogging as a better approach for aggregating structured content.

One of my focus being workflows around this concept (what I called Folkflows in my previous post), it will be interesting to see how this will progress. But the focus of this article is the very first application of Google Base (or for that matter, structured blogging): Simple match making. Like in classifieds.

Let us take a very simple use case: In my organization we have community newsgroups. People keep asking information about "recommend a doctor" or "where is a good restaurent in this location.". The information is amenable for google base: We will probably put up an interface to directly add the questions as well as results to google base. Both updates + search will be done using RSS or tab-separated file uploads, while giving some nice UI for standard shortcuts.

So what is the role of Google here?

Being able to store the attribute-value pairs and requests.
Be able to do matchmaking i.e. show the requests along with responses.

But we forget one more requirement: Be able to notify the people involved, and community. This is not exactly an atom feed problem: One can't subscribe to all individual feeds. For that matter, what is entry point of the feed is itself a question. Should I subscribe to a feed related "Anyone asking about anything in Pune, India"?

In some cases, it makes sense -for e.g. if I am tracking lowest prices of a particular product; but in most cases, we should realize that we are more attached to communities, and we will be ready to supply information to this closed community more easily than open-ended communities. This is a standard social fact.

This means, the feed that we subscribe to should be aggregation of all structured information at group/community level. It can't be a global feed based on item, given off by Google Base.

This model plays out very well when you add a simple Structured Data handling plugin to standard blog tools such as wordpress. And that is I would put Structured Blogging approach, integrated with standard feed servers is going to be important, and co-exist with Google Base. (We also note that group mailing list creation and management tools are also provided by google and yahoo, and they will obviously be integrated/enhanced to offer structured blogging.) We can assume that it is going to take some time to settle.

And folk-workflows will have to wait for attention till all this settle down.

Google Base will lead to "FolksFlows"

2005-11-16T18:25:00.000+05:30

Finally long awaited Google Base has been released.

The interesting thing is: There is no separate API required to use it. Because:

Adding an item can be done directly using RSS feed; with google specific extension tags.

You don't delete an item; you expire it by specifying expiry date. Perhaps we need to see whether we can overwrite an item with new expiration date. We would require some kind of key for this action.

You need RSS feed of a specific query in which you specify attribute-value pairs. Seems easy for me.

And labels act as schemas. Even though there is a lot of "control" - for e.g. can't specify a lot of words, there is enough power already. It is essentially a web-oriented database and it is going to make it easy for any application which fundamentally involves public data (such as looking for specific movies).

One question is: Would this database model result in Google making any inroads into enterprises over the time? For that matter, any other markets which are not driven by advertisements and end-consumers? For example, can small businesses hope to have applications hosted with this google database backend one day?

The answer seems to be "Yes, it will happen one day". The model opens up what I call "FolksFlows" - Workflows for general folks. What does this mean? Assume you want to set up a simple workflow. You have set of 10 sales people and you want to track sales on daily basis by these guys. Usual process is to get a guy to create a decent-sized application and worrying about things like how sales folks can update the data from field. But Google model will turn that upside down. We can now expect, with appropriate interfaces, a model where anyone can cookup a schema, use a wiki front end for UI, use google backend to store private data (this is tricky), and use Atom and other Web 2.0 approaches to provide interfaces. It can at most take about 2-3 hours by a common-sense oriented manager.

So the core of the problem is to use google database for private data. IMHO, it is actually easy part; I am sure Google will come out with a model for it as soon as Google base stabilizes. The second core of problem is: Ajaxi'fied Wiki front end that will use google base - and this is already in market by Dojo guys. And ISPs will follow suit as soon as someone targes one of the available open source wikis for this market (integrating, for e.g. Dojo toolkit for ajax-enabled widgets.)

Such apps can still use their own backend while using Google-provided standardized Schema. But Google Base will end up providing most easy way to integrate the app with other apps, and Integration is most difficult problem in these markets ...

So future is indeed exciting. Let us all hope FolksFlows will very soon become a reality!

-Vinod

Interdependence vs. Independence ...

2005-06-30T18:03:00.000+05:30

From rediff article on Sri Sri Ravi Shankar's visit to Kashmir:

First Look: Sri Sri Ravi Shankar: Shankar responded to separatist voices by saying: 'Now the people and nations need more of interdependence rather than independence to live peacefully.'

How true! And How Spontaneous!

Wiki systems as application initiation front-end

2005-05-09T13:18:00.000+05:30

Summary: Wiki systems can evolve to become "working area" for people; a kind of better desktop that integrates information from multiple applications. One step in this direction is to create simplified application front-ends - catered to specific task requirements most commonly required by users. (This would be a middle path between GUI driven/desktop approach and command line approach.)

A request in local unix newsgroup triggers this discussion. How can I see a sorted list of most recent 10 files in all of my home? Apart from usual 'see man pages' and even 'God helps those who read man pages' thingies, there was a largish issue that I am highlighting here. And how we could possibly tackle it by using wiki systems as our desktops.

As computing has progressed to more and more deeper levels of society, we should re-look at how quickly we can get the tasks done, especially when we are new to it. I am actually sad that after all these years, computers are still inaccessible to most (in true sense), and one has to fight to make it do what we want it to do.

The unix culture assumed that you learn once (at some decent time investments) and you will be very productive on the platform for rest of life. A simple concept of "terminal" and text-manipulation commands are sufficient. It also assumed that the users are intelligent enough to combine the tools and get the desired outputs themselves.

Windows GUI approach for applications, on the other hand, assumes no investments of time. Usually you can quickly figure out how to get something done. But then if you are better at computers, then you will certainly feel the limitedness of GUI. (This will obviously be contested by windows fans, but such is life: one can't experience everything, and make really comparative remarks anyway!) So a person requiring lot of flexibility gets stuck. There are other programmer-oriented interfaces such as VB, but then that's not exactly same in spirit as that of unix command line philosophy. A power user isn't necessarily a programmer. (We need to watch how new windows shell 'msh' will evolve: Udell has explored this here.)

So what is a middle ground, that allows intelligent users to create some most commonly required solutions and publish them in a way that other people can find and use easily? Essentially what you would do here is to reduce hundreds of combinations of use of combination of tools, to few - solution centric - uses which are known to be statistically the most required solutions.

What should be the approach?

Solution Creation: Make sure an application can read independent 'solution config file' that integrates config file and appropriate command line interfaces, input/output destinations etc. It can change its avatar as per the associated solution config file. Intelligent users create such solution-config files. (Usually it should be XML format.) Note that a solution may use more than one tools as well.
Solution discovery: A wiki integrates all such available solutions from multiple individuals' blogs or other publishing areas via RSS. Standardization is required to publish a solution via RSS.
Solution use by end user: This would be within wiki environment, where the solution is amenable to provide good interfaces to consume the results and to pass around the information to other topics. A notable feature of wiki is to create a topic that represents some data output by the solution (and hence making it independent of solution.) So specifying inputs for a specific use is by merely quoting wiki topics. Wiki's also provide easy markup for things like tables and lists.

More I think about it, it seems to me that wiki is indeed a good information integration platform that multiple applications can share. It will facilititate use of XML within the integration, and yet providing simple markup interface to that data if user decides to hand-edit the data in wiki microformats.

Perhaps it makes sense for google to provide such an integration if they will also provide applications to go with (now that our emails - that constitute most of the information - are also in gmail)....

... Anyway, we never know how these things evolve! But this would be an interesting watch, since it is an open area for innovation.

-Vinod

Weblications (blog by Adam Rifkin)

2004-12-28T14:21:00.000+05:30

Relax, Everything Is Deeply Intertwingled: Weblications:

"With web-based software, most users won't have to think about anything except the applications they use.
All the messy, changing stuff will be sitting on a server somewhere,
maintained by the kind of people who are good at that kind of thing...
Desktop software forces users to become system administrators.
Web-based software forces programmers to. There is less stress in
total, but more for the programmers..."

Unfortunately the state of web-based application development is rather sorry today. It is not as easy as simple native program development - inspite of all the MVC models, devel environments (such as Struts), and so on. There are simply so many mistakes one can make.

And, if ASP is the way to go, then what could enable rather a large scale offering of web-based applications for end users? A simple deployment environment from a big vendor such as yahoo or google. (Let us call them "deployment vendor"). Such an environment would

Provide a clean mechanism for creating standards-based front-ends but enhanced by rich-client capabilities offered by such vendors.

Be completely cross platform - since the deployment vendor can take care of variety of browser compatibility issues. And eventually be able to dictate a standard. (For example, we might reject a desktop platform because applications provided by google don't render well on its browser.)

Be able to create high availability capability due to caching and other technologies - bringing the ASP app to the nearest node.

Be able to offer a rich language processing and voice capabilities effectively creating better interaction with the applications.

Be able to support variety of platforms such as mobile devices, PDAs etc.

Provide offline capabilities.

And perhaps there are many other points. While most of these are usual ASP requirements, the enhancements because the vendor like google or yahoo have abundance of computing power, and can effectively create application development models around their infrastructure, is a different twist to traditional ASP.

And hopefully, these enhancements expressly incorporate principles of The web way.

Standardizing table syntax for wiki systems ...

2004-12-27T15:54:00.000+05:30

Online table editing is very valuable tool - especially in enterprise systems. It could allow a lot of use-cases that require use of database to be done in wiki system itself. Simple form-fills for adding new rows (apart from directly getting table edits) helps simple workflows to be created quickly.

Jotspot demonstrates this nicely, but it seems to hide the actual table data - perhaps storing it in a external datastore associated with the topic. But it is nice to store the table information in topic itself. (Bulk editing, no problems in renaming ...)

But unfortunately there is no standardized syntax for table within a wiki topic (of course we don't have any standard as of now). Wikipedia is evolving to be a great centralized resource, so might propel a standard creation process.

In this context, a useful link is discussion on table syntax:
Help:Table - From Meta; discussion about Wikimedia projects. In particular, even using XHTML as table syntax would help a lot: It might allow someone to create a nice table editing tool - with plugin approach to add semantics such as Spreadsheet ...

-Vinod

Brain would like to minimize the efforts ...

2004-12-27T15:43:00.000+05:30

Consider some of the threads in completely diverse fields:

Amit's Thoughts: Thoughts about pricing - wherein the article, while listing choices available in pricing, brings out the point that fine-grain choices such as (per-call or per-view) are more costly when you consider the cost of thinking involved in making right decisions. For the same reason, gmail (where you don't bother to delete the emails) is much better choice than quota-enabled emails because you have to bother about making choices with each email. And when you have too many choices to make, the cost of email increases.

Neuro-aesthetics, Perceptual Grammar, Art, and Usability by Suman Kumar, wherein he connects usability to the fact that humans would like to minimize the work by brain (and supported by another study in this area).

And perhaps in many other areas (such as Adam Bosworth's emphasis on simiplicity in user interfaces, APIs etc.) - the same theme repeats. And yet, when we design things, we don't give sufficient importance to the simplicity angle - especially when you consider the cost of thinking involved in using and interacting with systems.

And perhaps the same principle is source of the bad designs in the first place!

ASCILITE 2004: Augar, Raitman and Zhou - Teaching and learning online with wikis

2004-12-16T15:29:00.000+05:30

A well-researched article on effectiveness of wiki systems for online education: ASCILITE 2004: Augar, Raitman and Zhou - Teaching and learning online with wikis.

Using (X)Wiki for Creating S5 presentations - Demo at Xwiki

2004-12-15T19:54:00.000+05:30

Thanks to Ludovic Dubost for creating a demo of presentations authored using XWiki (using S5 CSS approach of Eric Meyer) - Link: XWiki . Demo . S5.

"Google suggest" Feature

2004-12-13T11:53:00.000+05:30

What a great feature! What appeals is the simplicity of the idea and the way it was implemented. Browser as a rich-client model is going to new heights, demonstrating some really interesting capabilities.

Implemented by a google engineer Kevin Gibbs - in his 20% "research" time (as is culture in google), the capability simply uses javascript to do remote RPC with server to get a list of suggested keywords as explroed by Adam Stiles in his blog.).

Any suggestions for Javascript-based SDKs for rich-client Apps?

Beautiful quote from Nisargadatta ...

2004-11-30T11:49:00.000+05:30

Nisargadatta : I Am That: "You observe the heart feeling, the mind thinking, the body acting; the very act of perceiving shows that you are not what you perceive."

-Vinod

PubSub: Competitor to Google? Idea of "Query sharing" frameworks ...

2004-11-22T20:07:00.000+05:30

PubSub is a new kid on the block, and might offer some competition to google. In short, it is an amplified version of "Google Alerts" - which allowed you to track the news as it happened and send you alerts. (For example, I could track "application wiki" and get an email (or use their app) of all weblogs/news sources which will have these keywords.

So could it be a google competitor? Because ratio of searches for "existing information" to "new information" is going to reduce over the time, it could well be. PubSub has solved the tough part of matching your queries with changing information anywhere in the web. (Well, "anywhere" is probably only blogs and news sources for now, but I guess they can track changing websites as well). So storing those queries for a long-term is not a big deal. When you have enough queries that you actually find most queries are repeats, then the system is, in essence, google - without having to store all the web pages, but only the fact that they have changed. (Well, google cache is still something we love!)

Coming to sharing queries, I think that PubSub people should assign it a high priority. Stored queries introduce browses on information, and that is always good. For example "Top tutorials in XML" is a browse, whereas "Tutorials in XML" will just be a search. Obviously, the framework would also have ranking and all that, but then reputation services are going to be next big thing, right?

RESTful Flex

2004-11-22T19:37:00.000+05:30

At last, the gap between standard HTML programming (which is primarily REST - if you design it well) and Flash-based designs which use single URL for whole application - has finally reduced with help of techniques from RESTful Flex.

But there is a fundamental thing that developers should remember: Interacting with flash application is a local activity without round trip times. So if you are forced to introduce round trip just because you want the app to be RESTful, I think it is not a good approach. Instead the URL in the browser should dynamically change with your interaction with the application.

Let me give example. Say you selected an user from the list, and want to send the URL by email to another friend. So selecting that user might trigger a URL-click, and some interaction between user and flash should ensure that URL will change in a browser, without actually going to the backend server. In other words, it is not a real URL click, but only a simulation.

-Vinod

S5: A Simple Standards-Based Slide Show System

2004-11-02T15:05:00.000+05:30

Somebody had to do it: Using CSS and Javascript to create good presentations. Eric Meyer's S5 is precisely the same.

And it is right-fit for Wiki-based presentations: You edit a wiki page and use S5 markup to create a presentation text. And let wiki show the presentation by including right CSS and javascript files.

Some wiki systems do provide slideshow plugins, but it would be nice to see this all-thought off approach getting incorporated in them.

-Vinod

2004-11-02T14:26:00.000+05:30

The JavaScript Weblog - javascript.weblogsinc.com - tracks interesting javascript-based tools and techniques.

Koranteng's Toli: On GMail and DHTML architecture again

2004-10-28T13:44:00.000+05:30

From Koranteng's Toli: On GMail and DHTML architecture again:

The pattern is simple:
Database <-> XML (Optional) <--> JavaScript Object Bindings <--> UI Bindings (HTML) + UI management code

Wiki systems should map macros to make it easy to add some of the UI capabilities (such as adding an element to the already displayed list). Usual wiki renders everything in a page from scratch. In this model, you request only incremental info (using versions), and integrate that with what is displayed on UI.

But that would mean that all elements of wiki topic need to be accessed using structured approach. And perhaps we require fine-grain addressing of individual data items within the topic.

Tab (Notification) Framework - Usecase

2004-10-25T16:52:00.000+05:30

Suppose you get an email from your organization survey system (requesting your info related to company-organized party). How do we optimize the interaction with the app?

The very first thing: This poll calls for notification mechanism - typically by email. Hopefully that would have a URL in the email body that directly takes you to the right app and topic (assuming you are online). (A grave mistake if there is no URL - you are forced to navigate with multitude of clicks!)

But there are problems: I might not attend to it right now. May be I need some other info. May be I want to process it at specific time only - along with many other such emails in the same group. So either you end up bookmarking it, or marking the email for later processing. In essence, you now have to manage it i.e. create a personal workflow for yourself.

So it greatly adds to email overload.

What is the solution? Suppose this email integrates into the PIM application - as a task, with what I call as Active Bookmark, then it would be very easy to process all the tasks. The active bookmark will not only have URL, but it will primarily notify the state of the app - much like presense information in IM systems. Green = You still have time to respond, Yellow = You ought to interact very soon, and RED = Urgent. And some color for "Dead" - where you failed to provide the info in time and it is recorded by your boss :-(.

Now these active bookmarks are basicaly "Saved tabs" i.e. it would be very nice to have this as end-user functionality, so it doesn't depend on the application. Users can then manage how they want to process long-term information.

-Vinod

Designing for tabbed browsing - the "Tab Framework"

2004-10-25T16:02:00.000+05:30

One thing I hate about Bloglines is that I can't open the sites into new tabs directly - because each link is basically a javascript and not a URL per-se. In the same breath, I also like the fact that individual articles can be opened in independent tabs.

With tabbed browsing becoming such an important part of life, how should applications be developed so as to give best experience to user?

Use REST principle. Typically each tab should stand for independent object which is getting inspected by the user - in case the site is information oriented (such as amazon, bloglines etc.)
Alternately, if the site is workflow oriented (which most enterprise sites do), the tabs would probably stand for an initiation of workflow. And perhaps a small icon representing the "Data is now available" condition so as to get our attention when a delay-causing condition happens.
Similarly collaborative sites could incorporate some mechanisms: Has user become alive again? Is there a new discussion?

Second big problem is: How do we manage so many tags? For a moment, consider tags to be bookmarks. Each tag vies for our attention. While in most cases tags are temporary "handles" for helping us react to large amount of information, the actual attention span required might be quite large.

For example, workflows might involve a sign-off from co-worker, and all this while, you might want to keep the tab open (rather than remember to open the application again, or get notified by email.)

Some contexts might be really long-term: I might want to track a discussion, or wait to see if someone is selling that iPod at pricepoint of interest to me.

So as we don't have a decent notification system in place, I think tabs should get an important status.

Or perhaps merge PIM systems and tabs. Let one flow into another. And did I say that Email clients will greatly be helped by tabbing too?! (Incidently there is a slashdot discussion: Firefox as Platform. )

-Vinod

2004-10-25T10:11:00.000+05:30

The article How To Use Instiki As CMS in Instiki covers some important aspects of wiki and publishing (that I referred to in my previous blog entry.)

Instiki - Focus on Content publishing in wiki systems

2004-10-22T09:07:00.000+05:30

Spate of recent wiki announcements - such as application-oriented wiki JotSpot . For enterprise focus, being able to create application workflows in quick way is going to be important - in such a way that you can reuse the schemas and "code", and wikis provide just the right framework for the same. We essentially need to make sure that both the skillsets and time required to introduce a new workflow within the IT infrastructure will have to be reduced significantly.

And another wiki - Instiki on the block. The key feature of this wiki is being able to publish to different URL, which is more important from content-management perspective (which is another main theme in enterprises).

Publishing is not well implemented in current set of wiki systems. What capabilities do we require (assuming content is prepared for collaboration)?

Be able to produce good HTML, along with appropriate styles etc. Usually this means casting the content into one of the standard templates such as a news item, standard process information document and as such.
Make it an independent document, with careful control of outgoing links. Within a wiki system, links are introduced automatically - just by refering to Camel-Case (and similar) topic names. But in published content, the links are usually minimized, and made sure that they refer to previously published information only. So the the publishing algorithm should identify and inform the content authors to make sure the links are properly resolved. (And, it is better to provide them as an appendix or notes.)
Version of published documents (as visible to the audience) is not related to versioning provided by Wiki systems. The published versions of documents are for formal communication purposes. Usually a manual table can be included (which tracks published versions and maps it to wiki versions), but sometimes, this version information can be useful in overall enterprise content management systems. In which case, it needs to be available as metadata.
A good and flexible interface to create and manage navigation of published content. (Usually a hierarchy.) Wiki systems only provide a hierarchy for fast collaboration, and this is not usually sufficient for organization needs for published content. Accordingly, the embedded links need to be modified to refer to the published destinations.

Instiki says it makes it easy to publish information to new hierarchy of URLs. So this needs to be watched.

Desktop proxy needs to become standard service

2004-10-17T13:32:00.000+05:30

In Firefox history in Google Desktop Search, Jon Udell suggests use of local proxy to help store browser history, so google can search it. Well, this is only one of the reasons for proxy, there are many others:

Manage roaming IP addresses. Desktop proxy can do whatever possible to automate identification of network, so no need to change proxy addresses for all your desktop applications such as all those native blogging clients, IM apps, VoIP apps and so on.
Supports virtual machines such as colinux. I run colinux on windows to get linux via cygwin/X. But colinux needs to connect to external world. Proxy that provides NAT support is of course a first priority.
Hide those browser connection timeouts.When you switch networks frequently (i.e. when mobile), the TCP/IP timeouts tend to be very distracting. Browsers tend to hang (and later, give a "can't connect" alert box which you are forced to click on.) With proxy, you have easier approach: The proxy can give latest status and request you if you need to be notified nicely later on.
Cache content. Mechanisms to cache content in intelligent way, so it is available when offline.
Local virtual views on content (This is more related to wiki concept.) It is mich easier to organize content with help of a native app. Integrate it with locally running wiki to give access to your older content.
Selectively share information with friends. Since proxies run as http servers, it is easier to share content with friends - at least within the organizations. When you want to share across firewalls, an independent server can make the task easier.
Last but not the least, a good search interface.As suggested by Udell, the search integration can happen at proxy level. We require control over desktop/intranet/internet searches. For e.g. address searches can be directed to intranet, but the interface for it needs to become more intutive (select buttons? a leading string such as 'addr userA'?) More importantly, the proxy can identify the context and make sure the intention of search is better understood.

But we have these functionalities in bits and pieces. With focus on mobility, I guess there is scope for some good product on these lines.

DNA seen through the eyes of a coder

2004-10-07T11:16:00.000+05:30

DNA seen through the eyes of a coder - Something that most programmers will immediately appreciate!

-Vinod

2004-09-23T14:03:00.000+05:30

Pollard's Principles of Knowledge Management - a concise and great set of ground realities that the organizations need to be awre of with respect to Knowledge Management infrastructure. Must read.

In particular, I liked Knowledge Workers Don't Know How to do Knowledge Work due to information overload, Knowledge is Best Transferred by Conversations and we need to respect that, Everyone Learns, Organizes and Processes Information Differently - and so integration among various tools is important, Management Doesn't Want or Need KM Decision Support because they are hired for their expertise and decision making - for which they don't depend on other knowledge, and most important - Stories are Critical to Knowledge Transfer - eventually it is storytelling that is most effective.

"Your mouse follows mine" Bookmarklet idea ... ("What am I doing now?" protocol)

2004-09-20T11:55:00.000+05:30

As I move my mouse cursor over a webpage, I would like my peer (who is also seeing the same web page) to have his mouse cursor point to same information. As if we are sharing a screen - but not one of those methods such as netmeeting, but a simple open mechanism. Very useful add-on to wiki systems - makes it simple to "discuss" around same themes in a organizational setting. (Of course, you discuss over phone or IM).

The architecture will need a central server: You report mouse location (within the DOM!) to this server and your peer will listen on these events. Ideally this should be part of blog server itself and a simple mechanism to allow your peers to subscribe to your events.

This also leads to extension of blog concept to a generalization of protocol for exchanging "What I am doing now" - in real time. For example the sites I am visiting just now, or research I am doing. The interested folks from the community can join together and produce a common blog as a result. (Such an interaction often tends to be more productive.)

Perhaps someone already has this implementation!

Google can enable access-controlled searches!

2004-08-31T18:34:00.000+05:30

With the current infrastructure, google is in inevitable position to enable Access controlled searches.

What is meant by access-controlled search? Basically I would like some of my own content to be searchable by some of my friends. This is probably something that most social sites want to add; but can't add because most of such information is in emails (or in desktop).

Why is google (through gmail) in a good position to implement this? Here is the recipe:

Allow labels to group the contacts. (This in itself is a major value addition - see more notes below.)
Emails get the labels from contacts (in addition to labels associated directly).
Mark labels with "Allow this content to be visible from the associated contacts"
Modify gmail search box to search among contacts. (This search will give results from contact's mailboxes assuming they have labelled the content.)

In essence, to me it looks like best possible UI for access controlled search based on contacts: Associate labels to contacts and mark the label with read permissions. One could even mark it as "public" and let it be searchable by google - after masking off From/To/Cc and dates.

In any case, the real problem is: "How do we label the content efficiently?" Labeling contacts is easy and done only once (such as "Family", "My School Friends", "My new startup biz contacts", "VCs".) This in turn allows emails from those contacts to have same label and this is good thing.

This might as well be a killer feature for google.

-Vinod

2004-08-31T11:16:00.000+05:30

Domain specific languages express software refinements (June 2004) elaborates on:

Need for DSLs - a vehicles that allow layering in software specifications, in turn helping in isolating implementation details from the upper layers.
To what an extent XML can be used for this purpose
The requirement for ease of hand-coding (or at least use of standard tools) - -- I hold the same view, see one of my earlier posts on this topic

On the last point: We require a very standard (= available in all plugins, open source, small enough to download/install etc.) graphical visualizer for XML to ease "handcoding" of XML and some basic reporting from it.

-Vinod

XML structure without XML markup (Alternative markups)

2004-08-30T23:50:00.000+05:30

A old post - madbean.com: On verbosity, Ant's syntax and XML takes an ANT specification (in XML) and specifies the same into SOX and SLiP formats.

Other formats include YAML
Pyxie and SXML.

Counter rants for wiki rants!

2004-08-19T18:43:00.000+05:30

JimmoWorld: rant: Why I Hate Wiki/Twiki/SnipSnap/etc..:

They are overused, often for no better reason than "because we can". As a side effect, wiki nazis are starting to crawl out of the woodwork and harangue people who don't use wiki for their own pages.
I'm used to hand-authoring html and css. I hate the lack of fine control over my layout and structure.
Ugly to look at, often horrible to navigate. I've seen some truly incomprehensible sites with hideous layouts where it's hard to find the information you're looking for, if it even exists at all (not that this is unique to wiki-like resources)
Yet another grungy, nasty syntax to learn. Yeah I could learn it but I'm bored and fed up with learning new ways to do things slower and uglier than before.
Come on, be honest. How many wiki pages have you seen where little or no collaboration actually takes place anyway? Yeah. Loads.
Contradiction in terms though it may be, snipsnap both sucks and blows.

As I am writing this, I had to open the source of the page, navigate through lot of CSS, javascript etc. and then copy the relevant "block" that is blockquoted above. All because my browser-based editor doesn't allow me HTML cut-paste.

But then, this is exactly where wiki would have helped. Within a wiki system such as twiki, I would have just viewed the source, which is usually very very clean. I would have cut-paste plain text, and basically don't have to bother about the HTML markup. The "real" wiki markup tends to be some 5-10 concepts (lists, paragraphs, tables, head ...), so you shouldn't even say it really takes time. (Especially when the help is just below.) It is, in some sense, like learning email/news etiquettes!

Then the next point is ugliness. Since everyone has to use common denomitor, the wiki topics tend to be very bland. But many wiki systems allow templates, skins and inline CSS styles, which can be easily used to give a deadly look and feel. (Unfortunate thing is that there are no good tools, so usually one person in team takes responsibility for right templates, good colors etc.) And web-based publishing is itself a skill.

Then comes the navigation. Wiki topics tend to be graphically connected (as opposed to hierarchy), and so it might indeed be a bad experience. But it is also possible to provide special gateway topics, category topics etc., and you can still navigate easily. (Having a "Related topics" entry helps here.) At the end of the day, it is just a matter of good practice that everyone has to adopt.

At the end of the day, we should realize that managing information on web is as important skill as email, and is already a required skill in many teams which depend on collaboration. The existing skills such as managing information in a file folder or email are individual-oriented, and can't be useful in collaborative environments. And you can't always dedicate an expert to manage web-based published information.... Blogs have helped in "opening" of information, and wikis will help in organizing that information.

One issue is a good notification infrastructure: How can I track 15 odd topics that I would be interested in? RSS interfaces to wiki systems are solving that problem.

So I would say wiki systems are a necessity, and if anything, let us hope that good tools will evolve to make the experience smooth.

2004-08-15T00:51:00.000+05:30

Eclipse: Write Once, Run Everywhere Platform gives a good overview of how Eclipse is being used not just as IDE, but for variety of independent uses, including Rich Client App framework, Testing framework etc.

A Distributed Rich Client Application using SWT (eclipse component) ...

2004-08-14T23:10:00.000+05:30

Qanyon World Factbook - A Distributed Rich Client Application is a good starting point for those who want to create native cross platform apps.

One of the key requirement is that the download size of developed app needs to be as small as possible, and with a single click install capability.

Seems that this app meets these constraits rather nicely! A good choice for offline / mobile apps.

In the same go, the same site (http://www.quanyon.com/) has eclipse plugin for converting various file formats (such as excel) into XML for use in eclipse plugins.

-Vinod

publish-subscribe on the web ...

2004-08-14T21:46:00.000+05:30

Discovered mod_pubsub homepage today. Obviously very useful for mobilf/offline apps.

Simplicity in interfaces?

2004-08-11T19:46:00.000+05:30

In KISS and The Mom Factor, Adam Bosworth brings reality to surface: People like simple things. In this context, he explains how simple XML as part of HTML body solves most of the problems for most of the people - as opposed to SOAP/Web Services etc.

Readability, being able to hand-code the protocol strings (for a quick testing) etc. are very essential. Perhaps ideal approach is to makeprotocols and specs simple for hand-coding use and progressively becomes complex as you use more and more involved features.

This is specially true for wiki interfaces where markup is almost always handcoded. For e.g. a simple table with few rows and columns is a breeze. In TWiki, you can manage more complex tables by adding a macro (with handled it via special UI). But this approach is still limited because the simple markup characters such as "|" can't be used in cell's text (in which case, they mess up the complete layout). It is, in theory, possible to encode these characters and make each cell more complex (additional markup for protecting special chars etc.,). But since it helps only 5-10% of use cases (perhaps much less!), I guess no one will bother.

Use of tools can allow more complex markups, but then the fundamental premise is altered. I guess no one will truly feel at home with tools unless they know they can manage the generated code. For example, many CSS tools generate very good markup. And some of the CSS plugins in Firefox allow you hand-edit this type of CSS and see the changes live. (But not sure whether such manual changes will be read again properly by tool; in CSS it seems to be easy.) I used to hope for such an approach in TeX world, but it never happened.

My colleague also pointed out this old article from Michael Fitzgerald explaining why RELAX NG might be preferable to XML schema.

2004-08-04T10:21:00.000+05:30

A good article from eweek on Expertise management: Voluntary vs. automatic approaches to find experts: Expertise Management: Who Knows About This?. It is very important difference and has cultural aspects involved (apart from Privacy issues).

2004-07-23T22:01:00.000+05:30

Indexing outlook mails: A good article by Jon Udel: XML.com: Using Python, Jython, and Lucene to Search Outlook Email

Providing (multi-dimensional) Tab-based views on wiki topics

2004-07-23T14:12:00.000+05:30

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

2004-07-20T11:09:00.000+05:30

[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.

2004-07-15T23:46:00.000+05:30

Manageability - Open Source Knowledge Management Solutions Written in Java a good number of available software for KM (java focused).

2004-07-15T15:57:00.000+05:30

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

2004-07-11T07:41:00.000+05:30

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!)

2004-07-10T21:19:00.000+05:30

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.

2004-07-10T20:13:00.000+05:30

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?

2004-07-03T07:21:00.000+05:30

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!

2004-07-02T08:00:00.000+05:30
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.

Eric Newcomer: SQL is Dead

2004-06-23T15:25:00.000+05:30
In Eric Newcomer's Weblog: SQL is Dead Eric writes:

"On the other hand, applications like airline reservations and buying concert tickets will probably always need structured data, since they rely upon the ability to accurately manage shared access to a single data item instance (i.e. the airplane or concert hall seat) so that it is sold only once and on a first come first served basis."

"Applications like purchase order approval, medical records distribution, expense report filing, engineering and repair drawing distribution, safety inspections, and so on, really do not derive any benefit from the significant effort required to structure their data."

The information in the latter list of apps is primarily consumed by end users. Even if these apps have some structure, it is primarily to aid local manipulation (such as totaling, sorting) and not something that requires a full-fledged DB.

And though no one does it today, I believe wiki's can, in-theory, become front ends for apps such as these; much like tcl can be used as scripting front end for the apps.

Generic Mechanism for tracking changed wiki topics?

2004-06-09T09:39:00.000+05:30
Tracking changes in a typical wiki-based repository is not an easy task. Of course, you have 'Changes' topic in most wiki implementation, but what is important is to subscribe to changes of topics of our interest.

One of the ways is to let browser track changes. You create a topic listing interested topics. The URLs generated for these topics should become different when topic changes - so browser will treat them as 'yet-to-visit' URLs. For this, wiki product authors should change the algorithm that generates URLs that includes its latest version.

But there is a problem: The URLs don't look clean (i.e. version information is otherwise useless. In fact, if it is stored elsewhere, you might end up seeing older version of topic, not the latest.

So a better approach is to simply create a macro that will generate URL with version. Or some syntactic notation such as Topic:latest. (Latest to be replaced by its version no.).

Any other suggestions?

Drag-and-drop approach to create and manage project/knowledge spaces

2004-06-09T07:09:00.000+05:30
There is talk of a new drag and drop tool for pulling contents from different stores into sharepoint at OutlookMT and SharePoint (and referenced by Microsoft's Scobleizer at Drag-and-drop Outlook blogging for Sharepoint). Definitely useful for knowledge management.

At Persistent, we have developed a sharepoint webpart to create and maintain a project space. This tool helps pull emails from exchange or IMAP, extract documents and be able to add notes to these documents etc. If anyone is interested, we would be happy to provide the the beta versions.

Within wiki environment, you edit the topic in browser's text box to create a knowledge base topic. You can also upload documents (one by one) and put references to them, cut-paste from emails, reference other topics and URLs.

Good thing is that you can indeed publish quite a good web page with lists and tables. Bad thing is, it is not efficient. The ideal mechanism is to do drag-and drop into publishable areas. As of today, we can drag-and-drop URLs, and perhaps use the new WebDAV enabling plug-ins to manage the documents using explorer. But we need to be able to do it for multiple data sources. And the "drop" part should directly go to containers such as tables and lists.

This being a key differentiating and useful feature, sharepoint has definitely scored a point here.

Raymie Stata/Bloomba: "My Info Is In Here Somewhere"

2004-06-07T17:53:00.000+05:30
Statalabs makes a very usable, responsive and "server-class" (as Raymie calls it) email client - Bloomba. In the INBOX event, Raymie explains why search needs to be given much more importance than organizing data in the first place. (INBOX Event - My Info Is In Here Somewhere):
Back to 1995 yahoo vs. Alta Vista, Alta won't work because:
* USers don't know how to formulate queries
* Users don't want to see irrelevant hits
* Search wont scale
* Wont make money :-)

and
Subconciously some small part of the brain says I can trust the search.

Interestingly, one of the key decision point for any client-side email product is whether it should extend outlook (i.e. plugin), or an independent product (in which case, it better look like outlook) - as bloomba is. Downside for the latter is that you are forced to integrate calendar and everything else that outlook provides: In essence replicating most functionality of email. (It is actually a good thing for industry and innovation.)

And bloomba seems to have got the right chord: Search being so important (and unoptimized in a most versions of outlook), it will be perceived as completely independent capability. And possibly helped by mental mapping to google. So bloomba is in much better position to succeed.

And perhaps those who want to mine email data should partner with bloomba! You will hopefully not have to struggle with all those email file formats, and depend on bloomba ecosystem for the same.

Clay Shirky on Wiki's and Processes

2004-06-07T15:31:00.000+05:30
Clay Shirky in Wiki's Graffiti and Process:
Process is an embedded reaction to prior stupidity.

and
A wiki in the hands of a healthy community works. A wiki in the hands of an indifferent community fails...

And an example he gives: some graffity entries on site http://wikitravel.org/ were removed in less than two hours.

Ben Hide has some interesting counterpoints on why processes are required:
The challenge in making a community that functions well is creating something out of those talents that is closer to the maximum over the diverse talents rather then the maximum of their lack of skills.

Processes are required to create a "minimum standard" for a particular task, especially when a person is new to task. These are available through checklists and templates, references collected etc. in previous similar tasks. In my experience, I have seen that if the task we are performing has "wiki-enabled" people, there are lot of optimizations: We already work against checklists, quickly gather relevant details in one place, and in general, meticulously manage the information through the task.

But if there were other people, it is usually a fallback on email-enabled communication (and a lot of meetings thrown in). While we can't really compare the quality of the results, the overall experience is bit more taxing, involves more time. There is never a sense of "having taken care of it all" and "Am I missing something?". I have sometimes forgotten simple tasks such as spell-checking after "queuing" it to be done before submission.

I used to often forget the mobile charger before an important travel. But now, a 'travel checklist' that sits in my home wiki takes care of these things!

Sharing labels of blog entries ...

2004-06-05T20:24:00.000+05:30
If you are maintaining multiple blogs, how do you make them available to users? As independent feeds or a combined feed?

The idea case is of course to mark posts with one or more labels. And let the users subscribe to one or more labels.

This is specially true of sites such as blogger or Always on which have many members and publish multiple blogs.

The algorithm for selecting blogs will now become bit more compicated; rather than just pulling in the URL of feed, you would use a subscription-wizard to browse through a list of blogs and subscribe to the ones matching the labels you are interested in.

But is there more practical use for this? With so much of information around, labeling and selection based on labeling are going to be key issues. After all, labeling is not necessarily efficient when performed at the time of creating / accessing content; it is done when content is found useful - typically when you search for information in particular context. And such a labeling process is performed assuming the information will be useful later, and it may not.

But collaborative labeling is indeed useful: If I label some information, it would be useful to everyone else. But what should be the infrastructure for it? For example, gmail allows labels to be put on emails. But: (1) I need to create my own list of labels; can't borrow it from some generic list available off the web, and customized by me (2) I can't send this labeling information along with email I create, so it is duplicate work by recipient (3) If the sender adds new labels to a thread of communication after emails were received, there is no way to share them.

Of course, automatic categorization and better search techniques might remove the need for labeling in the first place.

Perhaps more debate is needed on these lines.

Are you CIO? Then read this eweek article!!

2004-05-31T19:39:00.000+05:30
I came across this eweek article today Finding Middle Ground in Office Use of Collaboration Tools. It is very pertinent to the fundamental culture of organization:

I had a fascinating conversation with a CIO the other day. He was complaining about how users at his company were running roughshod over corporate systems and networks.

The most recent problems came to light when a network failure cut off e-mail and Web access throughout the company's far-flung operations.

Instead of simply calling it a day, creative employees quickly implemented workarounds. One group installed a quick and dirty Wiki to enable team communications.

Another took advantage of America Online Inc.'s Instant Messenger application to route files and messages between geographically remote employees. Others used Web e-mail and wireless networking to keep the company's business flowing.

The CIO's response was predictable: He moved quickly to lock down corporate desktops and laptops to prohibit users from installing unapproved software or accessing unsupported Web services.

Needless to say, the responsibilities of CIO are different from those of other people who do the real work. Everyone tries to save their skin. What if these tools indeed create a security risk that will result in a major problem for organiazation? The overall optimization suffers because different parts of organization are not acting in sync.

And that is the real challenge: How do you let your daughter to go out late in the night, and yet be worried about her safety? Something can still be done here: You can be liberal by nature. But in a large organization, with different people having different visibilities, it proves to be quite a difficult task.

Those companies which enable the right culture will obviously thrive!

Fast Company | It's A Blog World After All

2004-05-25T19:09:00.000+05:30
Fast Company | It's A Blog World After All - tracks some of the companies which are allowing their employees to blog.

I am still not aware how much of blogging happens internal to an organization i.e. it is necessarily access controlled, and more specific to internal needs such as projects related info, internal news etc.

Blog Software Breakdown

2004-05-25T19:06:00.000+05:30
Blog Software Breakdown gives a very nice table of different blog software such as bosxom, Movabletype, bBlog etc - 10 of them. And a host of features.

If you are new to blogs, then it is a good link to understand what you can expect in a blog site.

Email and RSS compared.

2004-05-25T19:00:00.000+05:30
Email v RSS, let us move on... has a very nice table comparing what is good and bad between Email and RSS on various fronts such as Email marketer perspective and customer perspective.

Note: This is very nice table, so worth the visit.

-Vinod

How much better can the the communication interfaces be? (Thinmail)

2004-05-25T18:57:00.000+05:30
A very interesting service I came across today: Thinmail. And Thinfax, Thinphone, Mobcall.

From their blurb from Mobcall for example:

Thinmail's newest service, Mobcall, provides instant push-button teleconferencing. It is triggered by sending an email message to any number of phones. They ring and whoever answers pushes a button and joins your conference call.

And similarly simple and interesting interfaces to all others services.

By conicidence, I also came to know of another service today - teleflip.com. Allows you to send SMS to any phone in US just by using phoneno@teleflip.com.

-Vinod

Email is "attention management" and not "content management"!

2004-05-25T18:38:00.000+05:30
Finally, someone from athority says it!! Check out EDventure :: the future of mail - and other topics:

the real value of the new mail, though, will be attention management rather than content management. In an iterative process based on explicit user instructions and watching of user behavior, mail will start to know what you want to see now, what you want to see later (and when), and what you want to see never.

I'm eager to hear about actual examples of these kinds of tools, and I hope to see a lot of them at Inbox. More when I know more.

Well, we will watch the blogs since we can't attend this important event!

One thing to add: As email moves to notification, the content will have to remain on the web. And that content is useless if you are on the move. So you ought to integrate that with synchronization tools; in other words, how nicely can you replicate that web on the laptop - without requiring any intervention from the user.

Bill Gates Comments on evolution of email and sharepoint integration, Blogging

2004-05-24T16:27:00.000+05:30
Bill Gates on information management (in recent CEO Summit):

Likewise, e-mail suffers when you have lots of people collaborating and different attachments that are going back and forth. And the creation of this idea that, whenever you want to work with somebody, you just create a Web site -- called a SharePoint Web site -- that's been very explosive in the last year as we've built that more into Office. Office, even if you have the latest, will make a hint that when you send an e-mailed attachment that, do you really just want to click here and we'll just make a Web site that everybody can go to and see what's going on there?

What happens very quickly when a company adopts that is you get all different templates for these shared Web sites for starting a project, for doing a meeting, for discussing what's going on with a customer. It's phenomenal to see how quickly that takes place. So, the next generation of collaboration really is about bottoms-up creation of Web sites where the IT department doesn't have to get involved. In fact, you can just have a few people administering 50,000 different sites and those sites get staged out and everything in a simple way.

In essense, the focus is on increase in business productivity due to integration of various tools. Sharepoint will continue to get a lot of attention. More importantly, he also gives an idea of how these tools evolve; primary focus being the templates for specific work. This is in essence a mechanism to create dynamic workflows.

The quote about being able to administer 50000 different sites is interesting: Why so many sites? Because each is typically context and activity specific. These activities will be active for only some time, and will disappear; the resulting website should just be archived over the time. So the mechanism of being able to quickly create context specific website is going to be very important.

The email integration is going to be the key factor that decides the success of this approach. Blogs specifically allow you to not bother about To's and CC's. In emailing this does take some amount of time. By blogging, you save this time, and put onus of information consumption to the group in general.

And another problem that Gates focuses is to be able to get notifications from changing websites, sharepoint sites and blogs. How nicely can the notifications be integrated and delivered?

In essence, there is no doubt that the information management area is now under microscope, and we will see a lot of good products to manage information overload.

-Vinod

Providing RSS/Atom interfaces over emails

2004-05-24T15:02:00.000+05:30
As more and more tools are becoming available for managing numerous blog feeds, how could we use them to make it easy to manage emails as well?

For mailing lists, there are some solutions:

http://www.bloglines.com/ is my favourite feed aggregator service, and many good features. It allows you to get RSS feeds of mailing lists (or any emails) by allowing you to send an email to a bloglines email account generated specifically for this purpose. Use this email ID to subscribe to mailing list.

MailBucket provides a service that allows you to direct a mailing list into a feed.

I am not aware of others.

Ideally I would like a tool for organization mails, and with access control. Cc'ing and/or forwarding to this email address will make the emails part of the feed. It also helps in managing the context for activity, since the feed name (which should be necessarily dynamic and easy to create) represents the context. Since the information is typically sensitive, the feed should only be available to the group. Perhaps only to members listed in each email item.

It is much better approach than mailing lists, because RSS aggregators help you manage multiple contexts in much nicer way. But "subscribing to feed" should be made simpler - with help of good integration, or perhaps a special feed that allows publishing of new feeds and allows easy subscriptions.

-Vinod

On creation of "browses" on your knowledge base / weblogs / Wikis

2004-05-21T11:45:00.000+05:30
What is the worth of information categorization - which happens by making it browsable?

Browses are essentially categories / sitemap layer on top of variety of documents / material that gets accumulated from various people. For examplt, Open directory project is a group-based browsing system created to capture the most useful links out there.

The information accumulation may happen under wiki systems, forums, weblogs, newsgroups and sometimes through emails.

While most people submit information, very few people create browsable interfaces for that information. Browses take the user to specific information, unlike searches and news (i.e. tracking changes) interfaces to the same information.

Creating "browsing" on the information will work for specific use cases - such as "What a new person joining the project should learn". In essence, this is a context. Some contexts have long-time validity (like in project-induction process) and some others have short time (such as proposal making).

Since browses are for specific activity/context, the overhead in creating a browse in advance needs to be carefully examined. For example, if a group starts to collaborate on a new process, members should probably put browses to identify "must-read" information by all members, to give context to the work, and to identify relevant documents within and outside of organization.

So it doesn't make sense to have "master browse" for information within organization, the people can browse through a list of activities, and then access the browsable information within that context. It also helps in why that information was relevant to that activity.

When a specific activity is started, how quickly you can let other people (not formally part of activity) to reach you with helpful content? Obviously, you would also like to filter the incoming information - typically this is based on relative expertise of the person is giving the information. In large organizations it would be very difficult to know real expertise levels. That is when you go look at the weblogs maintained by those people.

But it also helps to know "What is happening in organization now"; that is the only way the connections are made. (And that also explains why a canteen or coffee corner is strategically essential to any organization!). You require news like interface her: Which people are in news? What events are happening? What topics are being discussed? Here is an interesting tool: k-collector from evectors.com. It is an interesting approach for presenting information from weblogs (and possibly, from wikis as well): In terms of "What", "Where", "Who" and "when" boxes that give overview of what is happening in your organization (or in a community where the server is hosted). This is probably achieved by tagging appropriate information with weblog entries: such as people, places, events and so on.

The "optimality" of social-expertise and experience exchange tools will continue to be refined, and I hope some set patterns emerge giving a clear idea of what tools will result in better ROI.

-Vinod

2004-05-21T11:18:00.000+05:30
This informative take on KM (Presenting People Centred Knowledge Management at the CiG by Matt Mover). Creating communities when new contexts arise is important, and for that, social networks (in form of weblogs, chats, and wiki for information management) are essential. Nice quote: Weblogs + Topic Maps = Shared Context.

2004-05-20T15:18:00.000+05:30
Avoiding the "Gotchas" of Knowledge Management | Winter 2003/2004 Perspectives | ICF Consulting gives some good guidelines before embarking on setting up a KM system for your organization. (Same applies if you are trying to agree on wiki or some such technology for your group.)

In summary: Get involvement and complete backing from the senior management (at least 2 levels up!), make sure goals and objectives are understood, make sure you establish processes which are actually understood and followed by people, check out inertia effects and so on.

In a small group, things work fine because everyone is involved, and it is group effort, and things are likey to succeed. But the moment it is an effort where the audience is not personally in touch with you (i.e. you are doing it for much wider group), then you need to handle it in much more different way (heeding to suggestions such as ones from above link). People come from variety of background; they won't have visibility towards objectives and goals the way you do. Or perhaps, they have some suggestions to give from their experience... In essence, the success factors are not in your hands alone, and you have to take help from senior mentors, and so on.

2004-05-20T15:05:00.000+05:30
Kamoon Connect has Expertise management products, and rather good elevator pitches on their offerings. More importantly, the site is very pleasing and well organized.

2004-05-20T14:54:00.000+05:30
Came across a product/website that recognized ad-hoc and other various types of workflows: Long duration workflow process with activity suspension. In particular, how can we setup a process in a very short time so that some collaborative work is performed? This work can include collection of information from people, be able to route a document for review and approvals, be able to simply categorize and publish information. Also, the expected skillset to create this workflow should be very minimal.

Needless to say, wiki systems are moving towards this. Twiki is actually well placed to handle many such requirements in organizational settings.

-vinod

2004-03-12T13:16:00.000+05:30

Integrating wiki and NNTP servers

One of key problems with wiki systems are that the changes are not available in sequence, like in email. People have to visit the topic explicitly. With all due apologies to Joel's article Building Communities with Software (one of suggestions being not to incorporate email interfaces!), I think it is important to have email-like interfaces along with hierarchy and organization oriented access to wiki topics.

And the standards are yet again to our aid! I discovered nntp/rss - a tool that provides nntp service over aggregated RSS feeds. It is a a Java-based bridge between RSS feeds and NNTP clients. You can use your favourite newsreader (typically available with most email clients) to read the RSS syndicated content. Native readers provide rich experience anyway.

And wiki systems have usually incorporated capability to stream changes as RSS feeds. And that allows us to access wiki changes via newsreader. There are variations: Some feeds may only contain topic names, some others might contain complete topic content (leading to content replication, hogging disk space). But good thing is that news readers are supposed to expire the content after some time.

There are some caveats though:

We are still talking of one-way traffic here: you can only read the contents, but not modify using news interface. Online users can hit the link and directly use wiki editing. But many users are intimidated by wiki markup, and it is nice to be able to use newsreader editing capabilities (by posting topics). The postings are also useful to mobile users. More on this below.

A subtle problem is introduced due to access control mechanisms. Since news readers don't have access control, only information available to guests is made available via this mechanisms.

Neverthless, this is still useful, and I think easy to setup.

Mobile users have additional requirements: They want to replicate wiki topics that they normally visit on their laptops. This is partly solved by having newsgroup access since newsgroups can make information available offline.

Better still, once useful links are in newsgroups, a local robot can go and fetch these pages and make them available offline, in almost automated manner. (Note that you are using newsgroup subscription interface to list interesting webs and topics.)

And the final task would be to integrate replies to articles back into wiki. We require some standardization. We will also have to bother about conflicts.

So these solutions do deserve a good attention from enterprise IT shops!

-Vinod

2004-02-15T06:59:00.000+05:30

Interfacing external applications and utilities with wiki systems

I recently came across Prosper (http://prosper.sourceforge.net/) - which is a latex class for producing presentations from latex source. I am quite pleased with features - it gives control over animation and almost all aspects. Another application that I came across was jfree (http://www.jfree.org/jfreereport/index.html) a suite of java libraries that allow you to produce nice tables and outputs using XML definitions.

And the typical requirement is to collaboratively edit the sources and to generate the final files using these applications. There are two key problems: The input is in their native format (jfree may use XML) - and it is better to use wiki markup. Second, there should be a nice way to interface with external application so that the responsibility of writing connectors lies with these package owners and their users, rather than wiki system authors.

I think a unified mechanism for achieving these - across all wiki systems - is what we require here. More we standardize on wiki interfaces, more benefits will follow. Unfortunately, there is no standardization effort for many aspects of wiki systems - and that is indeed a bad news.

2004-02-02T23:16:00.000+05:30

Editors for wiki systems

In mobility architectures for wiki, it is important that we have a local editor on local wiki topics and files, which you sync with central server.

So local wiki editing within a browser, with light-weight http server running on your laptop or mobile device would be desired.

Editor in javascript or java applet are not always good options: They should be available across all platforms, should be fast and like native editors. In fact, I am typing this in blogger's javascript editor. Works in windows; probably not in mozilla (well; I never saw this there!).

But flash should offer a good option - it is after all all UI rich and is available across different platforms. (Suggestions welcome!)

Though there are many javascript based editors, we require integration with wiki systems: Primarily performing format conversions. So you indeed require a open source editor.

Perhaps we should wait for mozilla editor control!

2004-01-22T19:52:00.000+05:30

Wiki with offline functionality - targeting mobile users

Mobility is getting a lot of attention. Intel's Mobilized Software Initiative is an interesting big step in this direction. Applications written for mobile devices have characteristics very different from usual applications. For e.g. they should primarily assume that connection is available occassionally. They should also adapt themselves to change in form factor and other changes experienced if an app were to hop from one mobile device to another.

Given this context, how should wiki systems support mobility? For once, weblogs are popular because one can write them in offline mode (say, on PDAs) and submit them by ftp when you have connection. You can also sync RSS feeds and local app can put an UI. But not so with wiki systems. In fact, this one factor actually makes email attractive because people always have access to required information even on laptops in remote, unconnected locations.

The key to offline usage is caching and automatic updates. Applications such as Plucker and AvantGo do this, but they are primarily read-only. Semantics for wiki systems should be different.

Here are some thoughts that I came up with. First part: Use IMAP backend for wiki systems.

And that means, IMAP provides interface for read as well as writes to topics. Since versioning of topics is important, store each successive version of a topic as new email (IMAP APPEND command). Some people raise concern of too much storage requierd. But we can easily automate management of older topic versions and entries. Email tools will allow you to archive them nicely. The file/DB storage is still required: It is used as cache. As it is, twiki already uses two files per topic: One ",v" file - versioned contents, and another: actual file as seen during edit. The first one is now replaced with IMAP backend (and appropriate RCS like interfaces). The second one will primarily be current contents (used for implementing search, for e.g.), and associated cache information (see below).

And second part: Make wiki completely local to user. This means, wiki will create one hierarchy for each user (assuming that user writes contents, or wants to cache specific, subscribed pages). So wiki installation on server will primarily be published "read-only" content + user specific cache folders. On laptops, the user cache contents are replicated as is.

So, why is this useful? Because it gives ample opportunity for implementing Dynamic functions on Cache. This is new architecture that is being talked about (for e.g. Adam Bosworth's weblog). You require control over cached content in a way you can do some local activity there. For example, if you have cached contents of a table, then you should be able to sort locally on laptop.

The most interesting part: Wiki systems already provide the specification of this functionality. Its topics are mix of static and dynamic content specifications. For e.g. %DBQUERY{host=xxx query="SELECT ..."}% or %INCLUDE{http://www.google.com/}% primarily execute as dynamic queries. (The notation is specific to twiki, DB query is for example only.)

And then, some of the wiki systems also provide caching layer. If two users click on topic with contents such as above, the caching will happen and the second page is returned from cache.

But we require more control over caching. For one, I would like cache to be part of query, and not part of topic. This may mean adding of some metadata, associated with topic. Second, you require more specification - such as how often to cache, whether it has to navigate in remote website and cache everything. In some cases, it is heuristics: If web page has "Page 1" below, it should go ahead and cache that link as well.

When you do a SEARCH in twiki on a page which has INCLUDE, the search happens on dynamically included content; not on string "INCLUDE". This is important distinction. This is special to INCLUDE directive, but you require control over this aspect as well.

And then the last part is to allow users to modify the topics independently and use appropriate merging algorithms. Because of IMAP and email interface, we can send the changes by email. If auto-merge is not possible, conflict resolution screens can be processed after next sync.

In essence: I think wiki systems are already geared for mobility. With right integration, they can even help existing web sites to be experienced nicely in offline mode. If websites were to implement special web services, the wiki systems can easily incorporate them as plug-ins. And access control is already available and used in wiki designs.

What more can one ask for?

-Vinod

2003-12-07T13:37:00.000+05:30

Outliners

Outliners are a middle path between raw page edits (where users necessarily know Wiki markups) and completely structured data approach where they enter information through forms.

Found this nice article on the same: http://www.atpm.com/9.10/atpo.shtml .

2003-11-20T19:39:00.000+05:30

Comparing Wiki systems and Sharepoint: A different approach

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?

2003-11-17T15:11:00.000+05:30
One of the tools for 'innovation management' is to manage your ideas i.e. make sure you capture them when they arrive in flash, and spend time to do more thinking and researching, collect appropriate URLs and so on. My friend Girish sent in this URL in my mail today, pointing to http://www.innovationtools.com/ . And the very first thing that I liked was the discussion on outlining tool. Outlining tool helps organize thoughts in hierarchical manner, and allow you to keep multiple threads of thought; collapse and open any thread of thought.

In wiki systems, I almost always use outlining - using lists and sublists which most wikis support. The key difference is that you normally have independent topic for each thread. And these are not necessarily connected (i.e. available from one UI). One approach, for e.g. in twiki, is to use 'Idea' or some such word in topic name, and use search to collect and display all such topics in single page. But it is not quite same as what we want ideally: Have all threads simultaneously available.

Second problem is that wiki systems require you to be online by default. But ideas come primarily while you are offline, and it is easy to take out your pocket PC and put a line or two as notes. You require good synchronization capabilities to make this happen, and with a tool which makes its outlining data available in open format.

Perhaps a plug-in can be built where these concepts are integrated in well-integrated manner. We can use some commonly available tree controls using javascript.

2003-09-08T21:26:00.000+05:30

Row and column based access controls in wiki tables

For last couple of weeks, I have been working on row and column based access controls in tables in wiki systems. Topic owner should be able to give selective control over rows and columns to people.

More on this little later in this write up, but consider why tables are important in wiki. When you setup a wiki topic with table definitions (like EDITTABLE in twiki), it becomes very easy for people to add information: They don't have to worry about wiki aspects. This method helps you get contributions from people in organization much more easily. You don't even have to expose the fact that you are using wiki systems. Moreover, organization of information in tables is far more pleasing than (say) lists. And I normally attach columns such as 'last updated' and 'who filed the info'. These help in tracking the age of information, and also, make sure that you indirectly track ownership of information. At the end of the day, the information systems should be able to connect people together (especially in large organization).

My earlier successful attempt in this was to collect a large number (about 5-10 per topic, and 15-20 topic) of skillsets from about 300-400 people in just one afternoon. And we could create this in half a day - primarily being able to put special markup for Poll Plugin in twiki. And though the system was under a lot of stress (leading to high latencies), it never failed.

My effort in table access control is multi-fold: Focus on free-form collaboration, Be able to create ad-hoc processes, create semantic networks (see notes on IMV elsewhere in my weblog), and synchronization based approach towards information systems - to reduce schema management overhead in large organizations. I will comment on only one aspect here today. First, a quick overview of capabilities I experimented with: Specify acl attributes in table definition. For each column, specify who has access controls - something like 'owner:rw,boss:rw,mygroup:ro,all:rn'. This roughly means: Owner (or row, column) should be able to read+write, my boss (boss is usedid here) should also be able to do rw for all rows/columns. My group should be able to only read the rows/columns, and everyone should not be able to even read. (I also defined 'rb' - means, show the row/col as blank.). Columns can therefore be turned read-only, or may altogether disappear for some users. Similarly, rows ('owner' column contains the row owner) can be made visible to only owner and groups. It is even possible to allow users to specify additional 'ro' controls to some users.

Now let me put non-organizational use case: Suppose there are lot of wiki's around (a fact today) which support this model. The users define a table with schema definition pointing to some centralized website. Consider 'favourite movie' list as a wiki table, schema coming from centralized site. I would provide access to only my friends - say I would specify email addresses in ACL column. For now, let us not worry about actual implementation of ACLs. But the effect is: (1) I provide information about movies and ratings that I like/dislike, (2) specify movie lists for which I want similar information from other friends. Assuming we have standard webservices etc. (i.e. parsing tables across the web), an aggregator (much like RSS aggregators) collects movie information from friends and shows as part of same topic.

How we could leverage RSS for this? The designs will become clearer once we get more insights. For example, I envisage a markup in written weblog text - such as: //addtotable:movies/The Matrix, rating=5/. This markup should update the stationary table on my webpage (only once!) with either addition or updation of a row. For more information, check out http://twiki.org/cgi-bin/view/Plugins/EditTable2PluginDev.

2003-07-02T16:52:00.000+05:30

2003-07-02T16:09:00.000+05:30
Came across this Quickiwiki, Swiki, Twiki, Zwiki and the Plone Wars
Wiki as a PIM and Collaborative Content Tool by David Mattison, Access Services Archivist British Columbia Archives, Cananda.

A rather nice article on overview of Wiki systems. Right from the concepts and terminology, to a quick overview of the available (open source) wiki products, their useability and so on. Also, some thoughts on where the collaboration technology is headed - especially the academic projects.

Duly recommended to anyone who wants to have overview about wiki system of collaboration.

2003-06-20T12:27:00.000+05:30
A nice resource for combining Wikis and Weblogs:
http://www.ourpla.net/cgi-bin/pikie.cgi?WikiWeblogs

2003-06-12T11:06:00.000+05:30
I keep talking about Structured editing in twiki. Let me give more information about it.

By structured data, I mean typical tables, trees and so on. However, there is more to what I have in mind:

A render of a table in HTML will require different information contents. Wikis make it possible to edit these contents easily. First, let me list different contents:

MetaData (Schema). These topics define what data elements can exist. The model that I have in mind is based on IMV - a graph like relational system with distributed data in multiple data sources.
Data: Can come from multiple sources (especialy in wiki environment):
Database, via a database plugin. Specific columns can be listed.

Contents within the wiki page, as raw text, with delimiter such as '|'. Example: | email-id | Name | phone number. |'. This will have to migrate to YAML for want of completeness. For example, twiki doesn't easily allow multiple lines in a single cells. We have to use BR.

Attached document, excel sheet etc.

Virtual table, where individual rows can come from multiple topics. Twiki allows SEARCH, that can produce a table from data from multiple topics.

Variety of views on tables already in Twiki. A set of tables together can provide organizational schema. The views may consist of selected columns and selected rows. The selections can in-theory be like SQL selects.

Mechanisms to modify the data. The rendered views could be
Style for the table. Individual columns should get their width info from style specification for individual columns.
We require a clean system that will allow us to use variety of edit mechanisms on structured information. For example, 'edit' view on a table should probably introduce a column that will have 'edit this row' click button. On hitting it, you edit that single row.

Access controls. Normally this can be specified with schema, and perhaps as additional columns.

The challenge is to enable wiki environments to create organizational schema and extend it on continuous basis. For a smaller organization, we shouldn't require a separate database.
And when performance becomes an issue, the database should be in shadow i.e. no user intervention should be required in managing the database schema. It should be reflective of the schema specified in wiki environment.

Wiki environment will make it simple to manage information in distributed manner. For example, a table that can be specified in a topic may have INCLUDEs that come from other topics. So if you consider a user table, different sets of users are managed in different topics (probably under relevant group), and yet, you can have a centralized user table by appropriate INCLUDEs.

And you require capability to include columns as well. Let me give an example: In one topic, I may maintain user-id, user-name, email, phone-no. In another topic, which is maintained by some other people, they want to create a table with user-id, name, email, project name, role-in-project, and so on (i.e. project specific details.) And only a subset of users may be defined (only those belonging to the project.). This task is part of schema management. Topics can define and extend the schema, and make them available to other topics that will let the table be managed by INCLUDEing the topic schemas.

Advantages with respect to databases are many. Traditionally, the schemas are managed by applications, and databases are used underneath. And you can't easily generate new views and reports. Some specialized applications do provide such capability. But they all require that a database be used and managed. And this requires administrators for that purpose. Wiki environments push this functionality down to users. As a lead for small group in a big organization, I should be able to extend the organizational schema for my purposes. Wikis will allow us to do precisely this.

I have tried to experiment these ideas in twiki, using a modified Pollplugin, and Template toolkit. Only user specific information could be collected (i.e. each row has user-id as its key field.) But that is just a starting point; and a lot of things need to be understood and implemented.

2003-05-22T14:51:00.000+05:30
Java Wiki, especially the one using struts etc. should find a lot of interest from people. There is one: Chiki.

In trying to find out what people say about this, I came across this log: http://www.raibledesigns.com/page/rd/20021102?catname=General. Some wiki-centric thoughts put on this log, for example, this one. Evaluates different java wikis. Very Quick Wiki, SimpleWeb, Chiki and JSPWiki. Gives concise list of features with this one.

However, the log entry itself was old (Oct 2002), so we need to recheck on these.

2003-04-15T16:34:00.000+05:30
Synchronizing code ... with data models

A typical server side, enterprise application taps data from databases and other stores, transforms it, and makes it available to different access mechanisms such as web.

Typical synchronization mechanisms watch changing data at one datastore, and replicate them at another (possibly mobile, disconnected, replicated ...) datastore. 'Watching' either means polling the data to identify changes (less common), or inserting triggers into Databases, or accessing changelogs of LDAP directories.

But consider another case: How often you have to change the application code because the data model, or the schema changed? Are there regular patterns?

Some of such patterns are already observable. For example, if you choose LDAP as your datastore, you are shielding the data model from the applications to some extent. Adding a new attribute in LDAP will not require that you change your code. If you used good coding practices, the attributes could be made available to both business logic and presentation interfaces without having to change any piece of code.

However, business logic heavily depends on data models. And typically, the very purpose of adding new attribute would be to introduce new business logic. The term 'synchonization' in this context would mean that the business logic is expressed in adata transformation language model - for example XSLT. And it should be possible for us to create a synchronization model that connects Data model in backend stores, business logic in XSLT specifications, and Presentation layer components such as menus, lists etc.

One thing to note: In any synchronization, the changes happen independently at one point, and get replicated elsewhere. In this model, the changes would be driven by any layer. For example, I might use a website design tool to add a new attribute (say, "size") to an item being shopped, and expect it to appear in (say) LDAP schema automatically. Once introduced this way, this schema element might become available to other team members for use in other screens.

Does this model make sense? If it does, it would make it very easy to write applications.

2003-03-26T21:31:00.000+05:30
What is the "right" wiki to install and use? I have experience with twiki. While I don't recommend it whole-heartedly, one should consider it seriously. Let me give various factors that you should consider to make a decision. And apply these to other wikis.

Feature Set: Authentication, Access Control framework. Wiki is an environment that allows edits from web, and with a simplified markup, makes it easy to create and manage information. However, a typical corporate deployment will require a lot of other capabilities: Access control to pages, hierarchical webs, groups capability, and so on. You will also require authentication capabilities against sources such as LDAP servers. TWiki scores very well in all these. However, security is bit week.

Feature Set: Plugins for Integration with other data sources: One of useful functionality of twiki framework is its capability to integrate with databases and other data sources.

Deployment Environment.. Within an organization, you have to provision lot of users, make sure that performance characteristics are met. Security is another consideration. (And twiki has many security holes - Limiting access to a closed group.) If you are installing it with ISP, then you would typically want a CGI solution, which you could probably install in your area in the server. Twiki scores well in this aspect.

Manageability

Plugins

And so on. I will add to this list incrementally.

2003-03-21T16:16:00.000+05:30
Weblog with focus on Webservices:Loosely Coupled, Doug Kaye from RDS strategies.

2003-03-20T15:11:00.000+05:30

Is wiki useful for serious documentation?

Slashdot posting I made to a 'Ask Slashdot' question: Community Driven Documentation for Free Software? ( My post: Virtual Document: Distributed document editing ).

The discussion was towards whether or not wiki is a good way to do the documentation. Many people feel that it is a bad tool for documentation.

Documentation has more to do with a specific process, and especially so, for Documentation in collaborative, open-source like environments. The community has not matured in this respect, unlike, say, development of software.

What is required is a capability to allow document to be "Virtual" i.e. it is picked up from independent editable pages. This is very much like FAQ-O-Matic, but wiki can help in presenting a proper document structure by including different parts of document from different editable pages.

And each editable page may have a section, or couple of sub-sections. It may have owner or may not have owner. But all contributers may have to learn more than typical wiki formatting - to make sure that the document structure remains intact. And if the wiki tools can ensure document structure compliance by users, we should expect the strategy to result in good document.

As a general remark, the patterns for distributed management of shared information have not yet emerged - in contrast to individual communication tools such as email. Discussion boards are too simple to be useful in this regard; information management is key part of information sharing.

And since people tend to share information more easily in one-to-one emails, we require some good directives to be used during email composition, so that the data can be pushed to shared area. (And how you can format so that it can also be managed, is an interesting challenge.)

Update: This mail about use of wiki for documentation for Zope 3.

2003-03-05T22:17:00.000+05:30
James Britt's Weblog - on Information management and related issues is here: http://www.jamesbritt.com/

2003-03-05T22:16:00.000+05:30
Sean McGrath's article in ITWorld.com: Realities of electronic information management . Do you have time to choose data models for the organization? And most of the data models are extensions of what was used for the very first time the information system was designed anyway.

Neverthless, the models do influence how you can manage the information. Relational models are solid and proven. But then we also have Treel models (in LDAP), and general trend towards shared information model by multiple applications. Approach of SAP, PeopleSoft etc. is to hide even the relational model (with their supplied schemas), and provide an application layer for integration - but most such integration is custom-made.

In IMV, we believe that graph is the "right model" of data (and metadata), and like LDAP's tree model, it is the next generation model. Views are integral to these, and the actual mappings to underlying Database layers could be hidden. Query mechanisms in graph data will have to be developed, and may not even be optimal. How exactly DB technology can be used as underlying layer is yet to be seen. LDAP itself has not been deployed off DB's; most ldap servers use DBMs (i.e. table model of data).

2003-03-05T22:06:00.000+05:30
"Organization is a Giant Spreadsheet." - Vinod Dham, in: Economist.com: "How about Now". From John Rob's (http://jrobb.userland.com/2002/02/14.html) Weblog.

And on the subject of Information Management, another link: Zen, flow and emergence in information models.

2003-02-19T17:12:00.000+05:30

I was browsing through Nilesh's blog (techie, works at the company that is rolling out the biggest CDMA launch:-). A nicely written article on "Swarming" - a methodology in understanding complex systems, and coming out with solutions that work. Here is the URL of the log (and he gives nice examples):
Swarming, KM and Reliance

And his main question is: How come the big company, with very complex patterns of working, still produce great results? And he seems to find answers at http://www.lse.ac.uk/LSE/COMPLEX/Seminars/2001/report_19march01.htm. (Seminar Notes On 'Clustering and Swarming as self-organising techniques in virtual communities' by
by IBM's David Snowden.)

Some interesting notes on how Reliance actually practices some of these things.

2003-02-18T17:11:00.000+05:30
Wiki (and twiki in particular) are very good for "Information Organization". I am trying to get a better term; but let us go on. Please note: I am quoting the use case from a typical organization setup.

You are a service within a organization. You maintain information in an internal website, and you create some new pages related to some new activity. And then you use email to send the URL of the start page for this activity. And people are happy; they can access the pages.

Well, what is forgotten here? If I have to come back after few days, there is no way to remember the URL. I have to access the specific mail (which is more and more difficult these days - with so much of information overload.) More importantly, the information is limited to only specific users who received the mail in the first place.

What is the right way to do this? You want an area in Home page of the site, in which you put new 'Start page' links for any new activity taken up. In twiki, this is too easy to do: Just refer to the new page (though it is not created as yet) from home page, and click on '?' accompanying this link to create the actual start page for the activity.

Now what is the right term for this? Information management? - too general. Information Access Management? - too much managerial. OK, forget it.

BTW, Portals also allow you to do the same. But initiating a portal in an organization setup is usually a very big affair, costing lot of money and time. In such a case, adding a link becomes a business process. Why can't we do some things by common sense?

And geeks: Don't assume this point is too silly to list here. We are one of the top organizations, and I find it very difficult to get this conveyed to a lot of people. And of course, they are good in their own field.

2003-02-18T15:06:00.000+05:30
A good article on Backlinking: http://lightningfield.com/david/clips/0211backlinks.html. I got this from: http://www.disenchanted.com/dis/linkback.html.

Backlinking is perhaps the next revolution on web, after forward linking to different sites from a web page. Suppose I write an article. Say, some people read it and refer to this article from their weblogs or other sites. And I would like to know who all have done this type of linking (so I am able to read their views.) Now, either the web-based applications should co-operate (and this is easy when same application in all the sites), or a third party should visit both sites and somehow connect them. The latter is what is already possible on the web: The readers of the other sites will follow the link, and visit my site to see the complete article. In this process, sufficient information is collected and passed on by the browser of the visitor. This information is then made available in real time from my site.

Isn't that a revolution?

2003-02-18T14:42:00.000+05:30
Weblogs and TWiki Integration: Some links

These came off the topics I read in twiki.org.

http://www.lathi.net/twiki-bin/view/Main/BlosxomAndTWiki : Matt Wilkie writes about how he made blosxom render wiki-formatted information. (This weblog is in perl, and uses standard file formats - that is what most of us like!)

And, http://www.decafbad.com/news_archives/000280.phtml#000280 "TWiki + Automatic MT-Search = WeblogWithWiki" notes.

http://www.decafbad.com/news_archives/000244.phtml#000244: Movable Type plugin for Wiki Formatting and XML-RPC Filtering Pipelines. Came to know that there is a Text::WikiFormat perl module.

http://www.decafbad.com/twiki/bin/view/Main/WeblogWithWiki: Article on Weblog with Wiki concepts.

2003-02-18T12:18:00.000+05:30
I need to introduce IMV at some or the other point in time. (http://imv.sourceforge.net/).

IMV stands for Information Meta View. It is many things in one: A personally owned and managed data source, a data model in the form of graph (as opposed to tree in LDAP and relational tables in databases), a structured data aggregation framework among diversely distributed IMV data sources, and so on.

What is the main purpose? To have a framework that allows us to manage and share information in dynamically formed P2P networks. For example, if everyone shares information about the books they own (or have read) etc., it can result in a massive distributed database. The key point to note is that every individual appropriately maintains the information she owns, and subscibes/shares information that they like from among friends and contacts. We standardize the process of sharing, the data model, and capability to evolve meta data so that sharing actually happens.

This project started off some 3 years ago. It has survived till date mainly through project undertaken by engineering students. One version was also sponsored by the company I work for.

Over the time, we have learnt a lot of things. Firstly, Semantic Net does this and more. Neverthless, we don't actually have a system in place that allows us to do the things that we have envisaged. So the project is still valid.

Second, for the product to succeed in real world, it should follow rules of real world. It is opensource, and so, geeks will be the first to adopt it. However, we want to design in such a way that other communities - such as businesses, ISPs etc. find value in the model, and it should be easy for them to boot. Third, it is eventually intended for end users who are not computer savvy. They understand email well. And we want to extend the email model so that email can now be used with structured data.

Rishi Desai (http://rushi.desai.name/) and Pavan Reddy (at Persistent) - who created a WebDAV compliant IMV server. This server is now available and used by other projects. (This was first successful demonstration, and won couple of prizes too.)

Priyanka Grover (who was at Persistent earlier, and my wife) created the first server with IMAP as backend, and a Template based system as front end - with IMV metadata and tree exposed to people. Obviously, we had to learn lessons in UI: The tree view is not the right way to present the information to users.

A group from AIT, Pune (2001-2002 batch): Vinayak Sharma (vinayak_ait@hotmail.com), Amrit Pal Singh (amrit_sarao@hotmail.com), Indervir Singh (aitproject@hotmail.com), Navneet Singh Waraich (nswaraich@hotmail.com) - contibuted IMV Browser component in Mozilla 0.9.5 using XUL. The idea here was to be able to create dynamic tables from IMV data. IMV is an arbitrary graph. However, the views need to be table centric; they can then be published on web. Vivek Shende (mailto:svivek@persistent.co.in) co-ordinated this effort.

In the current year, we have two main projects:

A data store for IMV and any structured data, with some interesting characteristics. The group from PICT (anurag_chakravarti2002@yahoo.com and others) are working on this. The key point here is that we want applications to use "Structured Data Models" to interact with secondary storage. Further, we want to make it easy for end users to manage this type of storage. An example: The email client that uses this data model for the email lists will not see a file on disk. It will instead see a list that has no bottom. You put a new CD that contains a part of your emails (say from specific month during last year), and the application will instantly see the list grow - all be it with gaps that correspond to other CDs. Increasing volume of information will require a new model, and this is what we are trying to come up with.

Second project concerns modelling of IMV interfaces as seen from different stakeholders. Firstly the end users: They should just see an extension of email paradigm: They can compose a imvMail that asks "Does anyone have this book?" i.e. it requests the recipients to submit structured data to their own IMV data stores, and then allows that information to be aggregated (from the replies sent back) into a table. And then, there are 'application providers' who provide applications such as Books. (Application here is a meta data set with some basic workflow.) And then there are IMV server hosting people - like the web server hosting providers which make it possible for people to get IMV account, much like they get an email account. Note that we don't want centralized system such as yahoo or hotmail: The system has to be as distributed as possible. Two people from MIT, Pune (Amber Saxena - ambarseksena@hotmail.com is contact point.)

We are toying with different transports. First it was WebDAV protocol. But it is not popular. So now, we feel that we just use email transport, with specially formed MIME messages that carry IMV messages. And eventually we want to pave the way for email clients to enhance themselves to manage IMV data as well.

We are also working on IM based interfaces to IMV. This will be more natural language based interaction with IMV data store.

More on this later.

2003-02-18T10:38:00.000+05:30
http://www.mindjack.com/feature/spin.html: "Spinning the web: The realities of Online Reputation Management" by Nicholas Carroll.

Summary: Human beings take various cues in determining the reputation of person/organization they interact with. Direct interaction (face to face, or by phone) is very successful model, and involves taking cues from gestures, facial expressions etc. How did it change when email, usenet, web (and now weblogs, wiki) happened? Since people depend on written word alone, the reputation management becomes trickier. It can make or break a successful web venture.

The article talks about how web affected industries' reputation: For travel industry, it was downside and led to realistic price levels. On other hand home retailing industries such as L.L.Bean etc. could manage and enhance their reputation.

Two news articles related to facial expressions today:

"Secret revealed of Mona Lisa smile":
http://news.independent.co.uk/world/science_medical/story.jsp?story=379381.

Also: http://timesofindia.indiatimes.com/cms.dll/html/uncomp/articleshow?artid=37803371: "Scientists Unmask Face-Reading Secrets." This one even has reference to how some buddhist monks can accurately understand facial muscle contractions that last only 1/25th of second.

2003-02-14T13:36:00.000+05:30
Found a good weblog (hosted in radio): Internet Technology Watch. http://radio.weblogs.com/0100746/. Refers to wiki also: Why not have XML schema to talk to wiki servers?

2003-02-14T13:35:00.000+05:30

Theme: Information Management in various environments - viz Email, Wiki, Desktop, Web etc.

We will talk about: Information management in different environments. Primarily: Email, desktop, web, wiki. And can users get to keep their environment, and yet be able to achieve all objectives of usual information management requirements?

Most 'active' people in industry move around with a laptop. And they love and live in email.

Why? The primary reason: They always have access to most important information - mails, contacts, important documents and so on. The laptop platform is hard to replicate on other platforms such as PocketPCs or Palms.

And Emails play an important role here. Let us look at this from perspective of Information management. What is good about email? (Compared to other information management platforms such as web ...)
- You are triggered when new information arrives.
- You have very good search
- Information is browsable based on time and folders
- You can 'relate' to any piece of information: It remains same since you last saw it. Nothing changes "under the hood".
- Information replicates in the Inbox. This means, your 'view' of information is intact even when source changes. This is, in general, a good thing.

And bad things about email (at least in existing clients):
- Browsability, unlike web, is linear.
- Relation between information - in form of links (as in web pages) can't be introduced, nor the system can automatically create them. At most, you have threads. (You can also sort by sender which is also a relation.) But the whole system remains static.
- And "one bucket" model is not suitable for information management. We require context sensitive views. If I am in home, I would like to see a different inbox. If I am meeting a specific client, I would like to have different view. And all automatically. (BTW, does anyone else feel this is a requirement?)

AvantGo

AvantGo-type functionality: You view the same links, but information in them can keep changing.

twiki and other wiki systems

Main problem with wiki systems is that information "changes under the hood" because anyone can refactor the information. The model is good to write shared documents, but not for information management of what individuals like. However, this is easy to fix.

Second problem is: Information replication. Because of shared nature, this part is indeed difficult. Note that in email you never have to 'integrate information'. You only create new information - referring to other information as necessary (say when you reply to mails etc.)

.. continues.

2003-02-04T14:39:00.000+05:30
IWantToWriteAboutThis: Aggregating Structured data by Email. Traditional: Use Excel sheets, aggregate them into a database. How to do it 1. Nicely? 2. Without creating dependency on specific products?

2003-02-04T14:23:00.000+05:30

Managing Structured data in TWiki

I keep working with twiki. The ideas keep coming at fast pace.

These days I am working on making structured data manageable in twiki (and in general, wiki) framework. The Topic names provide a uniform resource locator (URL; yes, sometimes you need to spell it to highlight the significance!) which act as achors to specific sets of data you are interested in. This data could be a simple list, a set of rows of a table (for which, say, you are administratively responsible), and so on. Due to plug-in nature, the data could come from a Database, and yet be available in format we choose to keep them within the topic.

So first part is: How do you keep structured data in twiki, and yet make it editable? TWiki chooses to use simple lists with capitalized words in cases such as Access controls, groups etc. I am trying to use for the same purpose. The reasonings are:

It is XML in disguise. Even though YAML folks claim to contrary. At least you get some power of XML, and you don't lose anything.

Hand editable, if really required

Good support for perl. In fact, you can parse the YAML data and directly create Perl structures.

So, I have chosen it for specifying any structured content in TWiki topic. (Typically wrapped with some markup so the plugins can identify that what follows is structured data.)

The next step is to be able to display this data nicely - in variety of ways. I now have a plugin to do exactly this. Currently it works with table data. My idea is to couple this with variety of CSS styles so user can choose how he would like to see the table.

How do we add the content to this table? Either handedit the topic. Or use forms interface. I have this done already. However, we have to think and see what are other options. For example, SVG is an emerging standard. XForms is also another standard.

And then we require integration with Databases. It is no good if my table is part of topic. Some people feel that databases are end-all of all structured data. Though I don't quite agree, we should anyway respect the fact that they are extremely well supported, and provide good integration with other tools in enterprise.

It is easy if my data has to reside only within a database. A plug-in can then act as intermediary. The topic only contains table name, database name and may be the set of columns. (Or may be the SQL query.)

But this is not acceptable. Why?

The twiki topic is a "View". Even though it is dynamic view, capabilities such as Search would be far more effective if the view is materialized, and available to Search and other twiki functionalities.

Integration with Email: TWiki model currently is centralized; meaning the information being processed remains central. But because it is collaboration tool, it has to, eventually, support synchronization between multiple installations. Specifically, we would like to have twiki topics delivered by email, and if required, edited and sent as email. This can only work if the topic views are same as their actual contents.

So, it becomes clear that twiki topics should have an internal cache, and mechanisms to update it. There is already a Cache plugiin. But this is not sufficient; we require good control over caching behaviour. I plan to do a plugin that allows you to do "Render and Cache" i.e. it has two arguments: the content to render (typically INCLUDE or SEARCH), and second argument is actual cache. It either shows only contents of cache, or it updates the cache with rendered twiki markup, and then shows the page.

More on this design later.

2003-01-29T10:34:00.000+05:30
What is the right software medium in which you can play around with both structured and unstructured data?
Let us list some: (Let us consider some structured elements sucha s from, to etc.)

Email - Mainly unstructred. But some people may adopt standards such as using specific tags in subject line - to put some structure in information. This structure is typically used for classification etc. But it has good handle on people involved and so on.

Discussion boards and Newsgroups. Good classification of topics, but unfortunately nothing more than that. Often, the user IDs are not unversal.

TWiki. We will come to this later.

More to explore: How to build systems that will allow us to manage both structured and unstructured information in single framework?

2003-01-29T10:25:00.000+05:30
My experiences about wiki (TWiki), and thoughts that will integrate our experience about how best to achieve collaboration.