Month: May 2003

During the second-to-last presentation I attended at ETCon, I decided it was about time to try and drag the format of the collective annotations into some kind of order. There’s a certain amount of pleasure lost by overly structuring these things, but it was beginning to become clear that some people had such different levels of collaborative expertise that having a workable template to start off with might actually be a tremendously useful first step. I think I would expect any group of people who used Hydra regularly to swiftly find their own best model of working. But in the meantime: Hydra_Conference_Template.txt

Anyway – I thought I’d go through some of the basic decisions I made in producing this first draft. If people want to take it stage further and work to adapt it more or push it in a different direction, then they should feel free to do so…

• The template is seventy characters wide, which should mean that it can be easily copied and pasted into an e-mail without wrapping (and may even survive being indented if that e-mail is forwarded);
• All headings / headlines are in upper-case, because that’s the least likely format for all subsequent text to be formatted in. That means they should be easy to visually navigate;
• All ‘variables’ (ie. placeholders for information that will be added during the proceedings) are spaced with and surrounded by underscores. This makes it clear that they are a distinct kind of content, but more importantly means that a simple double-click in Hydra will select the whole variable allowing it to be replaced quickly;
• Instructions / tool-tips on how to use the template are surrounded by curly brackets again to distinguish them from characters that people are actually likely to utilise in the course of their annotations;
• All sections that could contain content with variable line-lengths have some initial space provided. This is for two main reasons – (1) so that people don’t have to start each annotation process by creating space which is time-consuming and can result in people over-writing one another in very busy sessions and (2) to make it clear immediately where user-generated content is supposed to be positioned;
• The distinction between real-time notes and references is quite arbitrary, except that it allows individuals to take on different roles through a presentation – one can decide to create an outline, others can annotate that outline, and one final one can decide merely to note down all references, or find articles online that support or refute the case being made on stage;
• There are two sections for putting information about yourself on the template. The first is for contributors and asks that people put in substantial information about themselves (they deserve to be contactable and the information they provide here can act as a kind of authority eg. “Oh it’s someone from Google commenting on this presentation about search engines- it’s probably worth reading…”)
• The second information section is the e-mail bounce-back. This is so that once the presentation is over and all the annotations have been completed, the owner of the Hydra document can easily send the paper to anyone who’s demonstrated interest. This is different from contributors for these reasons:
  • Someone may be merely a spectator and not a contributor (this is not uncommon – people can get multiple information streams concurrently and there’s value in getting a commentary, even if you don’t decide to add your own input);
  • Someone may wish to add the names of other interested parties who were not party to the initial process;
  • While it’s important to get information about contributors, actually having a whole range of information can present some trouble. Imagine trying to send out the document to all the participants and finding that to do so you had to cut and paste each e-mail address individually. If there are twenty contributors, this would become tedious quite quickly. But if there is a separate field where e-mail addresses are just inserted serially with commas in-between, then the whole list can just be cut-and-pasted into a TO: field and the document sent off immediately. Much neater… Much less annoying…
• The copyright notice is more of a placeholder than a formal declaration, but since it becomes impossible after the document has been closed in Hydra to see who wrote what, it seems impossible to actually enforce anyone who insists that hey wrote one particular part of the document. Someone more legally minded should probably look at that stuff. A Creative Commons license – in this case – would probably be a pretty good thing to apply here…

I’d be interested to hear the thoughts of anyone who has actively used this template in a conference situation. It’s simple, but I think it’s clear and hopefully some other people will find some utility in it…

I find the way in which communities self-organise totally fascinating – almost as fascinating as I find those situations where communities fail to self-organise. I always wonder what went wrong?, when really I should be asking what went right in the successful communities. It’s not at all an obvious thing that if you give people a highly structured space which truncates whole swathes of interactions that they’ll all turn into a utopian group of productive, collaborative citizens…

On Barbelith Underground – a community that I’ve been running for years now (with development help from Cal Henderson), we decided to allow everyone to change their displayed user-name as and when they wanted. Obviously confusion emerged initially as unhelpful people changed their handles at the drop of a penny. But gradually a consensus emerged – core identities became acknowledged but with florid epithets all around them. So a man who started as Tannhauser moves towards Haus as his core identity, with his name displayed on the board as (currently) The little Haus in the Priory. Each user seems to find a phrase that they identity with (in time), but then they recontextualise it as and when they want…

In Ancient Greek poetry, poets used epithets to make names fit the metrical patterns they composed within. So Hera became “White-Armed” in one place, and “Ox-eyed” elsewhere. Dawn (Eos), when she appears over the battelfield can be – but does not need to be – rododaktylos (rosy-fingered). These were stock-phrases, but they were also highly descriptive. Sometimes they reflected local variations in cultic origins or stories. But they all represented interesting and different facets of the divinity, hero or commoner…

If I was building Barbelith again, I wouldn’t recommend totally flexible displayed-user-names. But I’d want to capture some of the variety and richness of the world of the epithet. I’d get people to express a core identity (Haus, for example) from the beginning, but I’d also let them change their epithets (before and after their names) on the fly as and when they wanted to… It’s a simple way with members of a long-standing community – to pay respect to the way that human beings (over time) can be many things and yet also always themselves…

So the rumour is that Wikis are ugly. Lots of people seem to agree and a good few seem to be cheerfully prepared to engage in the debate. And I’m going to put myself on the line here and say that if any of you were thinking about offering me a job or something and are likely to get cross with me then I’m sorry but I’ve got to do it… Isn’t it obvious that it does not need to be this way? There’s no rulebook that says that Wikis have to look the way they do – no creationist spark of godhood that came down from on high and declared this particular appearance of editable websites the perfect one. This statement – that just because there’s a bit more of a barrier to architecting a ‘prettier’ Wiki means that they are inherently ugly – seems to me to be astonishingly strange. It’s like blaming evolution for someone’s misapplied make-up…

Now I’m not a man who begrudges the visceral / visual aspect of design. I think things should be as beautiful as they are usable. But it’s facile, surely, to compare the functionality and potential utility of two different (and potentially incredibly flexible) products and leave with the conclusion that you just like the prettier one!

“I’ve seen a sneak preview of an edit-this-page type of outliner that Marc Canter is working on, and I like it a lot better. Why? It doesn’t hurt to look at it, mostly. Silly? Maybe. But I know I’m not alone.”

I think there’s a an underlying theme behind a lot of reviews of this kind and it’s a rather old fashioned idea of fixed and stable products. The Wiki is considered a thing that works in a way, rather than a rough accumulation of various versions of the same rough concept – each of which has some benefits and some failings. Each of which could be nothing more than the first stage in a longer and more fruitful path of evolution. Each of which could be stripped down to its core and integrated with other sites – small bits of meme DNA grafted into message-boards or weblogs or even more static editorial pages. There is no product to review with finality- there is no here here (as Gertrude Stein might have been misquoted). So we dig around and we take what we like and we make new things – some will bed down and spread, others will not. Many will be spliced with each other once more…

No doubt in the future – now everyone is looking in their direction – Wikis will be even more flexible (or perhaps less flexible but more powerful or easy to use) than they are today. There are an infinite amount of potential developments – incremental or catastrophic – that we could be discussing. And in the meantime, yes, someone could probably find a way of making them prettier as well. In fact, I hope they do. But while we’re waiting for someone to do that (or doing it ourselves, in fact) – can’t we just try and bring the debate up a notch?