Figuring out the collaboration tools in our intranet toolbox
I see myself as a translator between people speaking military and information technology languages. These two groups come from different worlds and have very different views of the world. The military people likes to speak about requirements from a very abstract standpoint and think the details should be worked out by someone else. They rarely have any knowledge of what the market can offer so when they are invited to a technical demo of somekind they usually approve it if it looks somewhat useful. The IT-people on the other hand have a tendency to strive for cheap, simple and safe solutions which will get adopted if some people in uniform accepts it. So what does that leave us?
Well, it means that if a military officer see a need to collaborate around a text and they are shown a wiki they almost immediately embrace it since it does not really matter if it is a good solution. It is far better than anything they have to today. That is why I think we need to break down our needs into a basic set of tools and define what makes them differ. These tools need to be mutually exclusive:
And then you could add the spatial dimension to this. It is way different to collaborate if you are at the same place or not.
So that means that a Forum is basically a thread-based structuring of asynchronous messaging while a blog is a individually based contribution of content that can be asynchronously referenced and commented. On the other hand an application such as CoWord is doing real-time collaboration on content. The point of all this is to have some common set of references when evaluation different products and their potential use in the organisation. There is a huge difference in the way a real-time messaging tool can be used versus a tool which is asynchronous and lets you leave a message. Using a wiki in a live virtual meeting is therefore not the best solution.
A wiki on the other hand is a good example of asynchronous collaboration on content. So is most features found in enterprise content management systems such as Documentum and Alfresco.
Real-time collaborative editors have not really been a success yet even though their seem to be an obvious need for it in today’s connected world. Wikipedia has a nice article summarizing what is available today. Imaging four people working on a operation order where they each have their own cursor and writing at the same time. Science-fiction? No, try CoWord…
This toolset also gives us the chance to question product or rather protocol selections we take for granted. Take email for instance. Most people agree that we need that. The concept is familiar for many people and we know what it is used for. Or do we? Since it is basically the essence of asynchronous messaging I argue that it is exactly what we need and not email which is just one implementation of it. An implementation based on standards developed in the early 70-ies which is hopelessly out-dated when it comes to things like security and efficiency. So maybe we should require that particular kind of messaging instead and open up for other technical solutions for it rather than POP/SMTP/IMAP. This is of course particularly appropriate in closes systems which has no connections to the internet which means that ”email-interoperability” is no issue.
So before we cheer at some new collaboration or social media application we should analyze them against our toolbox items and it will be much easier to find out if we like the product or maybe just some part of it.
There are more stuff in the toolbox but I will come back to them in a later post.