Hydra-sation

Here at ETCon2003, a number of us have been using a MacOSX tool, Hydra to take notes on conference sessions.

Where usually this note-taking happens in a straight text editor, Hydra adds some interesting elements that make for a much more powerful experience.

First of all, Hydra is multi-user. So there are multiple authors taking notes simultaneously in the same document. When one person loses steam, another can pick up the slack. Typos can be back-corrected in near-real-time. References to articles and further information can be plugged in as a sidetrack.

In place, each author's work develops shading, and any individual author can be followed in real time through the document.

Secondly, Hydra uses Apple's Rendezvous implementation of ZeroConf to discover and identify authors on a local network in a smooth P2P manner, and to enable the sharing of the document over TCP/IP (which sharing can also be manually set without discovery for WAN situations). This local discovery service makes it easy to find a document to add your abilities to, or for any author to gain willing hands to assist in a task.

Socially, Hydra evinces elements of several other forms.

The realtime discussion or accretion of data is much like a working IRC (or other group chat) channel, focused on a task of discovery at any given moment.

The shared document workspace is very much like a wiki, and involves the same degrees of trust and sharing that wiki's depend upon. A single bad-actor could destroy a workspace fairly easily.

The discovery, activity and follow structures function very much like lightweight presentity systems.

The near-real-time knowledge sharing also takes on a very weblog-like overlay for a good conference.

This is not to say there aren't some limitations in this early release of Hydra. Some nice-to-haves have shown themselves.

First, once a document is taken out of its working state, all author addition/modification/presence information is lost. This metadata would prove very useful after the fact. As Hydra documents are saved as plain text, this (potentially voluminous) information would probably be best placed in a separate layover structure.

Secondly, the color-coding system is brittle in document workgroups of more than 4 or so - the colors should have a cleaner auto-discovery method per document, so overlaps in this lightweight visual identity don't occur.

Third, in presence of a bad-actor, the owner of a document should be able to selectively roll-back additions or changes to a document in a timescale (I'm thinking of a track-like display with SMPTE-like data).

Fourth, more granular permissioning for participants in a document would be useful in a conference setup. Denoting who can modify vs who can observe, for example.

Fifth, integration of this tool as a remote editing element for a wiki (meaning a virtual publishing out of the document off the owner's hard drive) would be powerful for wiki communities.

Finally, this should of course be a cross-platform friendly solution, though the structures of underlying OS's may prove a slight hindrance. Better, of course, would be for the versioning and diff'ing to be an open standard of some sort.

Posted by esinclai at April 25, 2003 09:50 AM |