This model represents the smallest unit of collaboration: one-to-one. This isn't about crowdsourcing or everybody working together, or any other grand web design.
It's pretty much the base unit for all the other collaboration models, although the behaviour of the models changes drastically as they get bigger, more complex and take on more participants.
We could almost call it 'making stuff with friends', as that is often how this model works out. It tends to build on human relationships that already exist, and enables the individuals involved to develop and create something almost as a by-product of their association, their friendship. Think of it as a conversation experienced through the development of a work.
Broken down, the model plays out like this: person A and person B use tools to help combine their creative output(s) in order to create a new shared work. It's as simple as that, and like a lot of simple things, incredibly powerful. And yet, for all its apparent simplicity, this a potentially fraught area. What follows is an examination of the issues – the set-up questions, the pitfalls, the ongoing nature of the relationship – thrown up by one-to-one collaboration.
Getting the deal together
Of course, the initial difficulties in setting up this kind of collaboration can be great. If I am person A, where is person B? What if the people that make stuff like you aren't your friends already? Why do you need someone else's help anyway, especially if a potential collaborator does stuff in a similar way to you; what would they add? Or what if they are your friend and you don't want to damage that relationship with something as risky as a shared enterprise? (This last concern might seem a little whimsical, but it’s actually deadly serious; it was certainly one of our major talking points when setting up Unthinkable, for instance).
It is precisely these questions that Ohm Force are trying to address with their new music collaboration studio software, Ohm Studio. I urge you to watch their teaser video as it pretty much sums up the collaborator's initial dilemma. How will I find someone that will make this work better, in ways that I can't? Maybe I'm a keyboard composer kind of guy, but what I really want is some great singing or some real bass and I just don't know those people. Ohm Force have realised that to create a piece of collaborative software, a good deal of functionality needs to be targeted at connecting the right people together. They could have missed that important point easily. After all, most creative tools that we use now focus entirely on the creative act: making music, doing design, writing, enhancing photographs and so on. The companies that make the industry-standard creative tools like to leave the human network issues to someone else.
So let's say you have found your collaborator through some kind of networked functionality. In Ohm Studio's case this is by searching the community, who have made themselves findable by describing and tagging their particular angle, be it an instrument, genre, or language spoken. You find your bass player, you hear some of their previous work, and it sounds just right. How does the deal work? Ohm Force have opted for a slightly skewed power relationship, quite possibly because the hierarchy it creates actually makes the collaboration process simpler. Instead of a flat structure where the participants all have an equal amount of control, Ohm Studio invests greater powers of editing and decision making in the originator of that particular piece of music or project.
In other words, the person who starts the track is able to remove the collaborative additions they don't like. Whether that system proves successful we won't know until it is launched later in the year. But what it does highlight is that digitally-connected collaborations enable people to work together who have not already built up a relationship and a trust for one another, and this is likely to lead to another set of social dilemmas. Excellent!
Digital tools continuously make the deal between collaborators obvious and real through the availability of functionality to each of the participants. Let's imagine you and I are writing a play together. In your tool there is no delete function, but in mine there is. You can add stuff and create away but only I can reduce and edit the combined work (essentially the Ohm Studio approach). The deal will feel skewed and potentially fail because the tool affords us different levels of power. This is the common approach for Content Management Systems – especially in corporate environments - where a strict hierarchy, something that reflects the organisation the collaborators work for, imposes an imbalance of power at the heart of the tool. Clearly organisations have thrived on hierarchical relationships, and absolutely rely on them to create sense and order of their combined efforts, but small-scale collaborations can easily be endangered by these unbalanced power relationships. This means that when looking for tools, we need to make sure we are choosing the right “class” of tool; a so-called business solution may be precisely what you don't want.
What the tools don't decide or even suggest is the route to legal or norm-based ownership - or at least not the tools I have come across. The question of how a digital collaboration will create a work with shared ownership is now a vital one. The tools we now use make it much more likely that shared works will come into being. There is clearly a need for humans to try to keep pace with the technology, and design simple ways to think about and articulate shared ownership. This is the sort of stuff that challenges even the most innovative of developers. Shortly after the launch of their Playstation 3 'user creativity' game Little Big Planet, Sony-owned UK games developer Media Molecule had to unravel some enormously complicated ramifications of the social and legal aspects of letting their community build stuff with each other. It's not they hadn't thought about it (they clearly had), but it is extremely difficult to test how people will actually collaborate with a tool before it's let loose on the public. This is because you are not doing the standard user testing of the functionality of your system, but rather testing to see if your system can cope with the societal norms that different creative cultures use to ensure trust and good working relations. These will be very different for 14-year-old boys creating new levels in Little Big Planet compared with, say, a 30-year-old media professional trying her hand at some in-game collaboration.
What we need to ask each other
Although we know intuitively that these questions are rarely made explicit, they will undoubtedly still shape the experience a pair of collaborators might make, irrespective of whether it is undertaken with digital technologies. It is likely that the new breed of digital tools we will come to use will play a role in finding ways to pose and represent a collaborator's preferences, particularly when the collaborators do not know each other well. These preferences could be expressed through such questions as:
- Can we edit each others' work or only our own contributions?
- What will you do if you don't like what I do?
- Who can say when the work is finished? Or is the work inherently unfinishable?
- What is the exit strategy if the collaboration isn't working?
- Do we both own everything, or only the parts we made?
- How do we agree on the life of the work after it is finished? And to what uses can it be put?
Exchanges through time
Let's assume the deal has been forged and I have my collaborator: how is this thing actually going to work?
Obviously both the relationship and the work are developed over time – neither sits still - and it is this time component that has an enormous impact on what kind of exchanges and development can happen. If the relationship is to be more than just talk, the exchange of some materials is going to be required.
Writers collaborating five years ago would have had to work very much asynchronously, but quite possibly in parallel. One writer might have tackled one section and then handed it over to the other for editing and improvements. Or maybe the opposite was happening at the same time: writer two was working on a different section and preparing to hand that over. The shared work would have been carved up into bite-sized chunks and swapped back and forth. At some point all the bits would have been through both writers several times, and one of the writers would have been elected to bring all the parts together in to a whole. Microsoft Word is likely to have been the tool both writers would have been using, with each writer paying careful attention to which version of the document they were working on, probably coming up with some naming convention to reduce confusion, and using email attachments to bounce the parts between them. Even by the time the whole had come together and their shared work stood as a single document, there would have been very many versions, drafts, chunks and revision scattered between the two writers' hard drives and email accounts, with all kinds of potential confusion.
The point here is that time, multiplied by a fiddly process, will naturally create complexity and confusion. And what this inevitably means for the collaborators is that they must spend as much of their time managing and tending to the process as they do making good stuff.
Google Docs began to change all that a couple of years ago. The first step, and real breakthrough, was to bring the writing application on to the web. Nobody now needed to install a version of the app on their machine. Secondly, Google enabled one document to be shared by many writers. In our previous incarnation as Double Shot, Simon and I used Google Docs from the get-go. What this initially meant for us, is that whenever I wrote something in a document that I was sharing with Simon, it would appear on his screen when he opened the document: there was now only one document, not one each, or a ragged history of versions on our separate machines. At first, this more synchronous form of writerly collaboration fairly freaked Simon and me out. We had been so well trained by Microsoft and frankly the whole desktop revolution, that we couldn't quite work out how this new mode of writing was going to be useful. And to be honest a couple of years ago it was pretty clunky. Often we would try and write in the same document at the same time only to find things disappearing and confusion on the rise. What we still knew for certain was that over time this was going to become the core tool that would enable our little company to operate out of multiple locations, so that instead of a shared city office, we had a shared memory, a live scratch pad for ideas and a single repository for our documents in progress.
Now mid-way through 2010 it is fair to say that Google have really cracked one of the thorniest of the problems we have been grappling with over those last two years: simultaneity, or, to use less highfalutin language, how to write the same document with multiple authors all going at it at the same time. The latest version furnishes each user with their own cursor, visible to themself, but also visible to their collaborators. Now I can be creating document headings while Matthew, Sarah and Simon fill in the sub-headings behind me or as is more often the case fix my terrible spelling as I go. (To add to the sense of how tools have allowed this kind of collaboration to flourish: we'll often do this while chatting over Skype.) We worry much less now both about how the process should work now, and about the risks of killing the document.
Although it is only early days, I genuinely feel that this kind of connected approach to thinking and writing is going to change the way humans write altogether. Without doubt it is going to have far-reaching consequences for education, both in the way school projects will be constructed to help teach the essential skills of collaboration and also in the way individuals are assessed when working within those collaborations.
Where this approach to simultaneous writing/reading has already had an impact is in the world of coding. Pair programming, an agile software development technique, has been around for a while now. Usually two programmers sit next to each other at one machine, one typing as the other continuously reviews the code. Every 30 minutes or so the pair will swap roles. This is classic one-on-one collaboration and has proved to be very effective in trapping errors early and finding a quicker route to create solutions to design challenges. More recently the same approach as been taken but with the programmers able to be in different locations. This is possible through the use of new tools like SubEthaEdit, a collaborative text editing programme designed specifically for writing code in tandem. Interestingly, these approaches seem to be favoured by people in the open source community or people making stuff for the web. There is still a great deal of suspicion from more traditional programmers delivering huge corporate systems who often haven't had the chance to experience these forms of collaboration in their projects and who doubt their serious usefulness.
That said, these cheap or free digital tools connected over the web have brought our company the possibility of synchronous collaboration, and this is now true for many small companies operating across disparate locations and time zones. At a CI KTN collaboration event I attended the other day, many people talked about the fact that they now worked in companies that simply couldn't have existed a few years ago. What these tools have done, not always by design, is massively increase the range of potential collaborators, because they have broken the time and space barrier. Exchanges between person A and B can now happen anytime and anywhere there is connection to the network, no-one has to wait to think up their next move and everyone that can connect is a potential partner. This can make for very heterogeneous groups, something that’s turned out to be very useful for solving creative challenges.
Now, although I just went a bit new-tech evangelical I want to make one thing clear: I am not deriding the use of email as some do. And I am certainly not wanting to relegate email’s use, or suggest that it has become outmoded. It hasn't. It is still revolutionary. In fact email has some very special characteristics that make it a brilliant one-to-one collaboration tool. It is non-intrusive, that is, it doesn't force the communicators to stop what they are doing to pay attention. It is gentle rather than abrupt, and its flexibility allows for a huge range of communication styles. It is near enough ubiquitous, which means you can collaborate with pretty much anyone through it. And it carries your materials alongside your communication.
Exchanges of material
Let's look a little more into how material is exchanged through digital collaboration. What is true for file sharing is also true for digital collaboration. The same progression in network capacity that has enabled media piracy and file-sharing has also unlocked digital collaboration in those media. It started with text (and computer code), then moved to photography and now over the last ten years to music and video.
As a result, if I want to work on a poem with you, then we have endless choices of approach because the network has had plenty of time to evolve solutions. We can exchange tiny text files back and forth or perhaps write it at the same time in a Google Doc. In fact, because a small text file can be opened in thousands of bits of software we could collaborate using mostly any tool - we could even do it all via email and never bother creating a document at all.
Not so if we want to make a video together. The network has only recently got to grips with video and even then only with video that is small and compressed. If we are going to work on video together, the materiality of that video really starts to matter. The video’s size, its compression, whether it is to remain layered with editable parts or be flattened all affect how we can work together, as does, of course, the choice of editing software we make.
I have been working with the artist Jim Noir on a music collaboration over the last couple of months. Luckily we use the same software. We initially sent two Ableton Live files each to the other, four tracks being worked on in total. Each of my tracks, just a bundle of loops really, were around 300Mb. As Ableton Live doesn't yet offer collaboration functionality within the program itself, it is down to the collaborators to work out how to do it. We opted for using YouSendIt to send these big files to each other and then began re-assembling them, adding our own material, creating some structure and then sending them back.
Our intention was to have these files go back and forth several times like a game of musical chess. Now truth be told, what we actually did was take the materials, add to them, move things around and then make a tiny mp3 file that we could send back quickly, so that we could hear the new work easily and get feedback. We did not send the big editable files back and forth. What the large file sizes did in this case was inhibit precisely the conversational and iterative development at which digital collaboration can excel. Although it is technically possible, the scale of the thing becomes a natural inhibitor.
Something else gets in the way of the lovely conversational mode that Google Docs allows for. When editing or producing video or sound, the projects often become full of plug-ins, wonderfully useful mini-applications that are likely to be owned by only one of the collaborators. For example, I may want to use an ethereal reverb plug-in that I have purchased, but that Jim doesn't have. I can't give him the plug-in, as that amounts to piracy. I can only hope that he has it, and nine out of ten times we have chosen different plug-ins (there are many thousands of these things). What this means for the materiality of the music that I give back to him, is that I have to make decisions that he can't undo. For instance, I have to apply that reverb at my end, in effect flattening the layers and reducing Jim's creative options. It is this problem that makes professional collaboration in big media like music and video fraught with difficulty right now; furthermore, these are the kinds of difficulty that most people who enjoy making things spend most of their time trying to avoid.
I would like to think that the bandwidth issue that makes rich media collaboration more difficult may well recede as the network gets better, but I doubt that is going to happen for some time.
Unintended consequences of tools
Closed systems like, say, Mindmeister or FreeMind that cannot be radically amended by the user ensure that the same tool is in everyone's hands. This allows for much easier transfer of projects, but leads to a much less configurable tool for the user, not likely to allow for wildly idiosyncratic use. This means that the large flamboyant and customisable creative tools we have learned to love turn out to be difficult to use in a truly collaborative way.
That said, I think the increase of collaborative culture in many of our human endeavours will now speed up those technology solutions. And, I hope, they’ll also provoke new ways to think about the shared licensing of software; maybe the default will become share rather than own. In the meantime, all digital collaborators will want to pause and give thought to what kind of material would be the easiest and most useful to pass back and forth.
Exchanges of thought
In this one-to-one model the participants are more than likely doing two things at the same time throughout the process: talking and making. The making requires specific tools and approaches to allow material to be shared; so does the talking.
Many tools have chat functions that allow participants to talk about the thing they are making quite separately. The mind mapping tool Mindmeister enables everyone to talk about the map they are working on, so that choices can be discussed and debated before a change is made or, indeed, critiqued after. These exchanges of thought have often been treated as ephemera, mere chat, or the means to a wonderful end, but we are now seeing a shift of approach. These conversations are becoming a natural way of documenting a work in progress, and can be seen as just as interesting as the work itself. Our talking tools give our projects an accessible history. If we use Skype or Google Wave we leave behind a trail of thoughts, links, documents, asides, jokes and general pointers to our humanity.
Digital technology has created a potential object out of all of our conversations that is reminiscent of the way poets often write to each other about their work. And just in the same way that the letters of poets occasionally get published and come to shine a different kind of light on the work itself, digital technology now allows our conversations to become public too, but at much less cost or effort. Assuming that letter writing is on the wane, it is in all of our interest that our creative tools can capture and associate our shared thinking with the work itself.
Sometimes talking and making become the same thing. Comedians Robert Popper and Peter Serafinowicz created the new religion Tarvuism by first exchanging and collecting thoughts in a wiki structure that came to be called the Tarvupedia. As they collected ideas in a place where they could both edit, create new structure and connect ideas together through the simple link, they realised they had their new work; this would become the public place where Tarvu's wisdom would live and grow. Because of the choice of collaboration tool they’d created a work that could grow naturally and be in public at the same time. It didn't need to be finished, and its growing nature might be the very thing that would build an audience.
A few good reasons for one-to-one digital collaboration?
Disrupting one's habits and patterns is what collaboration does best. The way I think, the way I use software, even my purpose can be completely changed by working with you.
There is a more positive reading of my earlier example about Ableton Live, where decisions get locked in because of the difficulty of keeping projects editable. It’s that someone else's decisions are bound to take you off of your normal course because you can't edit or delete them, only be moved by them: lock-in as creative disruptor.
What this leads to, if you are willing to accept it, is that half of the decisions are made for you. Digital technology is renowned for offering too many creative choices at every point in the process. Digital collaboration does something potentially very pleasant: it can reduce choice.
Another great facet of digital one to one collaboration is that it builds human critique right into the experience. Writers have long had the advantage, as have art students, of an editorial figure to call on to help challenge decisions and improve the work. Because those thought exchanges can now persist, comments can be pondered on and returned to. Our natural temptation to discount or even forget what we don't like or don't initially understand about someone else's views can be balanced out by digital technology's propensity to store and make visible our shared past.