Category: Social Software

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?

Right. I’m going to keep amending this post as I think of things to say and get other things done. I’m in the middle of a talk with Tim O’Reilly at the moment (how cool is my life), but I reckon I can concentrate on two things at once and talk a little bit about the last presentation I was at (Eric Bonabeau on Biological Computing). Or in fact – rather than talk about Eric Bonabeau’s talk, I’m going to talk a little about playing with Hydra and how around ten separate geeks collaborated to try and annotate and comment upon a discussion in real time… But first things first – the incredibly messy (and extremely entertaining to write) set of notes on the talk in question:

• annotating_biological_computing.txt

Right. What you can’t see on this document is which pieces were written by which people – and that’s a terrible shame because all that extra information that could be of use just vanishes when you save it to a disk. More to the point, it makes it really hard to demonstrate when it’s worked really well and when it’s fallen apart. So in this particular case I’ve done a set of screen-caps to illustrate what’s been going on:

• hydra_eric_biological.gif

More later (hopefully) on the experience of writing (messily and collaboratively) with Hydra. Addendum: Here’s a screen-cap of the participants all colour-coded as of the end of the eventhydra_tray.gif

I’ve been thinking a bit about instant messaging clients since I submitted my IM contacts to Buddyzoo. In order to upload my buddy lists I had to switch from iChat – my default messaging client – to AIM. For the first time in months I remembered how useful it is to produce groups of your contacts. I really miss that piece of functionality.

Anyway – around that point I started thinking about how iChat could handle groups like AIM, and I starting thinking about the power of having multiple buddy lists held in multiple windows. What would it be like if your AIM contacts could be picked up and dragged between multiple iChat windows – one for your friends, one for your co-workers, one for your family etc. You’d still only have one AIM account, of course, but it would be represented differently.

Perhaps – if you didn’t like multiple windows for each semantic group – you could dock them together – producing bespoke metagroups like “Friends and Family” versus “Work”. Maybe the places where the windows fused could become handles that allowed you to resize each pane individually.

And then I started thinking about the other effects that could have – what if each window handled login information separately? What if each one used the inbuilt AIM buddy-blocking system on-the-fly so you could spontaneously decide to disappear from the world of your work colleagues while staying online with all your friends and family. Or the other way around? It’s surely just an interface tweak? What do people think?

I’m going to take the unusual approach of linking through to a comment I’ve made on someone else’s site. The comment is flawed – it’s full of typos and errors and gets a bit over-excited every so often – but essentially I stand by most of it – particularly this part which is about the relationship between research/debate and hands-on experience running an online community:

From my response to ‘Falling in with the wrong crowd’
“There’s a pretension around our work that says that we’re scientists – but mostly weÔøΩre not – we’re artisans. We build things for people to use. We build things that extend the abilities of individuals in one way or another. As such people who work in this field should be doing apprenticeships as much as they should be doing research. They should be managing a community, understanding the tensions and the collapses, noticing the problems and the benefits, seeing where people get stuck and where they need to get stuck – where they need structure and where that structure will kill them.”