Evidently there’s a nice new ‘theory object’ neologism for the class of things of which Documents With Tails are members: blogjects.

Thanks for Stephen for reminding me to read that paper.

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

Have updated my music player to use the JACK low-latency realtime library for output, and replaced Mplayer with alsaplayer as the media player. Have also dropped the Meridian 518 and Yamaha decoder from the output chain, feeding audio straight into my Bryston via the music box’s onboard DACs.

Given the hardware (and purpose of the box), there’s little benefit to be had from the low-latency features of JACK, but the realtime support helps keep the output smooth in the face of other stuff running on the box (CD ripping, for example).

And something in the combination of the simplified signal path and JACK/alsaplayer has definitely tightened up the high end a bit more, which is always a good thing. If only I had some Vivids to audition this all properly!

Now what I really want to play with is to tweak JACK to emulate the 518’s noise shaping/upsampling algorithms. Later…

Have been playing with interfaces. Cluster now includes a daily calendar (see right) of what‘s on on the London music scene (that I’m interested in — big caveat!). This is generated by a perl script from PHPiCalendar RSS feed. At the moment this is from a single feed, but there is no reason this itself could not be generated from syndicated calendars (as and when this catches on).

You can never have too many recipes for a cheap, easy-to-administer mail server. Especially if it’s based on a modern code-base, includes aggressive anti-spam and anti-virus tools, and has a webby interface for (multiple) domain and account administration. The system outlined at web-cyradm.org is well on its way to serving as a good reference install for small-to-medium sites. To simplify installation for those who are more interested in evaluating the system than in the mechanics of its building, we’ve written up a set of notes for its installation on Debian Sarge, using ‘off-the-shelf’ packages for everything but the core Cyrus services. The notes are hugely indebted to the HOWTO on the web-cyradm site, and should be read in conjunction with the HOWTO, rather than instead of it.