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…