Cluster

diorama
[We've been kicking this around for a while -- interested to see what you all think.]

In any corporate workgroup environment — and even more so in asynchronous, loosely coupled networks of workgroups, it’s a nightmare trying to maintain oversight of project-related workflow. Attempts at solution generally try to impose a systems structure which straightjackets process, or which stamps out nuance and ingenuity.

At the worst — and all too often — this can result in what we call a diorama intranet: the metaphor relating to those awful museum displays of ‘life on the veldt’, wherein, to illustrate the lives of wild creatures, those same creatures are hunted down, shot, stuffed, and arranged, thousands of miles from their homes, into ‘lifelike’ tableaux. Documents in a diorama intranet have similarly been hunted down in the working environment where they are part of a dynamic process, tagged, bagged, and placed carefully on view in some other place where it’s an effort to access them, and where they are immediately out of context, out of date, and generally meaningless.

In the real world, we all know documents have legs — the ‘current final final approved’ version of the pitch might well be on someone’s desktop, rather than on the server ‘where it should be’. The challenge is in tracking the little devils down to whatever digital corner they’re hiding in, digging them out, and then tagging them so they can go back out into the wild and get on with their digital lives — being modified, shared, presented — while still being trackable and accessible by others when needed.

We’re believers in the small pieces, loosely joined approach — if we acknowledge that documents are lively members of a dynamic ecosystem, that they have legs, and that they’re hard to herd, then logically we should be more interested in having a way to grab hold of their tails when we need to know what’s going on, than in stuffing them and mounting them in the glass display case of some convoluted intranet.

Lately, we’ve been playing with simple ways of doing just that — and the prototype we’ve got couldn’t be more simple — implementing a simple trackback in MS Office documents via an open source XML-RPC stack, some VBA code, and using a WordPress-based blog as the central tracking mechanism, which gives us for free all manner of slicing, dicing and aggregation goodness on the reporting side.

Currently, it works like this: when users create a document, they are prompted to fill in as much metadata as possible — client, project, author, and so on. Then at each save- or close-point, the save dialogue box includes the option of ‘reporting back’ the document status to the central blog — where status can be as simple as ‘change’/'milestone’/’signed off’ — with the last adding a write lock so the document can’t be changed further. The data sent back to the blog can be as simple as the document status, or as in-depth as the entire document contents. At first check-in, each document is assigned a unique code and an individual post on the blog. This makes it very easy for glanceable updates on project status, for example. Crucially, it also informs without interrupting workflow, and keeps people in the knowledge loop — if someone wants the actual document, it’s not sitting stale and stuffed in an intranet: they have to contact the last modifier themselves, which potentially gives them access to other tacit knowledge, or at least initiates a conversation. Better all round.

Of course there are flaws in this — what of modifications done offline? What of documents which get deleted? And so on. We’re working on that. At the moment, we’re more interested in the feeling of what happens working like this, as opposed to the central command-and-control of rigid workflow systems and/or diorama intranets. More on this soon.