I do not think/work/create like a machine.

My thoughts flow freely and I tend to discover relationships between events (hence “Connecting the Dots” above in the Blog Header), so I like linking things – at least mentally. Why would I confine myself to the rigid directory & file structure that computers have forced on us for decades? There are better ways… let’s look at some.

A while ago Atlassian CEO Mike Cannon-Brookes wrote and excellent piece on how Enterprise Wikis Replace Shared Drives. Shared drives as collective document depositories are a disaster, we typically can’t determine where, to put things, and certainly don’t know where to find them. And if we do find a document, how do we know whether we have the latest version? How do we know who changed what in the dozen other copies with similar but cryptic filenames spread around the shared drive?

Wouldn’t it be easier to use the equivalent of a directory structure with meaningful names, the ability to attach longer narratives to our documents and find them easily via search and tags? That’s essentially what you get when you use an enterprise wiki as your “shared drive”. Think of not documents/files only, but the very reason they exist: in business we typically work on a few “projects” at any one time. If we create wikis / wiki pages for each project / function, the page content becomes the “narrative” that describes what we do, why and how, and further supporting details are in the document attachments. There really is no reason to bury documents (doc, xls, ppt) in some central dumping place (document depository) anymore – they belong to the wiki page (project description) where by definition they are in context. Of course they can be used in several other places, in different context, which is where linking comes handy – linking to wiki pages as well as other content (documents, web sites, etc).

Now that we established the wiki as the “glue” to tie all our documents together, let’s take a step further. As we get comfortable with the wiki, we’ll often wonder when to create a separate document and when to use native wiki pages. If your wiki supports a rich word processor, textual content can easily move in the wiki pages themselves. (Interestingly, Blogtronix, the Enterprise 2.0 platform vendor uses the “document” metaphor for what others call a wiki-page.) Of course whether we call them pages or documents, they should still be easy to share with “outsiders”, by using workspace or page-level permissions, or exporting to PDF and other file formats should you need to “detach” content and email it.
This works well for text, while for other needs we shoot out to the point applications and attach the resulting files (ppt, xls… etc.)

However, like I stated before, I do see the irony of working in an online collaboration platform (the wiki) yet having to upload/download attachments. Atlassian’s Webdav plugin for Confluence is an elegant solution (edit offline, save directly to the wiki), but for most other wikis the process involves far too many steps. Why not directly edit all these documents online? This of course takes us to the old debate whether the wiki should become the new office, or just the “integrator” holding the many pieces together. As a user, I don’t see why I should care: I just want seamless workflow between my wiki, spreadsheet, presentation manager, project management tool …etc. Such integration is easier when all applications/documents are online, and there are excellent applications from Zoho, ThinkFree, Editgrid, Google, to do just that.

Working directly on the Web is not just a matter of convenience. Zoho’s Raju Vegesna points to mobility, sharing & collaboration, presence & communication, auto-Versioning, auto-save, access & edit history as native benefits of web-documents.

As we link web documents to each other, and smoothly transition between applications, a paradigm shift occurs: the definition of what we call a “document” expands. Offline, a document equals a file, defined by application constraints. Spreadsheets, presentations need to be saved in their own specific format, and they become “black boxes”: there’s not much we know about them, other than a short title. There is an overhead in opening every one of them, they need to be virus-checked, then “stitched” together to support the “flow-thinking” I was referring to earlier.
Those boundaries are stretched on the web: a document is no longer a file of a specific type, generated by a specific application: it’s a logical unit, defined by context, which weaves together content created by several applications.

Zoho’s Notebook is an experimental application that allows us to create, merge and store information the way we think, no matter whether it involves writing text, drawing charts, shapes, crunching numbers or recording/playing videos. Experimental in the sense that we don’t know how it will be used. In fact I don’t know what the future web worker productivity / collaboration tools will look like, but I suspect they will have elements of Notebook – multi-format, multi-media – and wikis – user-created structure, everything linked to everything – merged together.

Files, formats become irrelevant: there is only one format, and it’s the Web, defined by URL’s.

Additional reading:

• Shared Docs: Gateway Drug to Wikis?
• Document Management vs Knowledge Management
• Wiki as alternative to document management and email

Update (11/13/07): Read I Hate Files on Collaboration Loop. (via Stewart Mader)