Tag Archives: ctp

The Tools

We started looking for suitable collaborative tools by looking at Gartners Magic Quadrant for Social Software in the Workplace – a lovely chart that plots all the movers and shakers in the social media space. We could quickly rule out tools that seemed too CRMy, had a pricing model that ruled them out (i.e per user) or too business focussed. After a few rounds of testing we were left looking at….

The Candidate Tools

SocialText – a commercial enterprise wiki with a social layer


One of the most interesting things about SocialText are what it calls Signals, which are a bit like Twitter for the organisation, except Signals include tweet-like messages AND document changes. Very nice. We found the blogging tools very poor though – with blog posts essentially being wiki pages.

Like most wikis you can embed tags to give pages more functionality (such as showing a list of Recent Changes, or items from a Delicious feed etc). This means that you can cobble the functionality you need together very quickly. One example we played with was for the IT Support Office to individually use Delicious to bookmark and tag fixes they found out in the rest of the web and have them “collected” back on their wiki pages.


One of the “killer” features of SocialText is it’s Desktop application which, like email, tells you when something new has happened. This is an essentially component of any new collaborative tool because it “pulls you back” rather than becoming “another place to check”.

Jive – a commercial forum-based tool with wikis and blogs etc


Jive has a lot of polish with regards to the interface. It is easy to create content.

LifeRay Portal and LifeRay Social Office – a java-based, open source portal tool


LifeRay is an astounding product. When you initially log in, you just drag the components you need into your community site ( pages, wikis, blogs, calendars ) and then invite people in. This is staggeringly easy to do, like having a Ning-builder (but better). The LifeRay Social Office suite is sort of a “pre-built” version of the portal.

If you have ANY java abilities at all this is worth a look. I was slightly scared by having to compile CSS into jar files to change the look and feel and work with a gazillion XML files but some people can eat that geekery for breakfast.

Elgg – a php-based “community in the box”


Elgg is immediately likeable. You create Groups that have blogs, discussions, files, wiki pages etc. The problem with Elgg (for us at least) was to do with the permissions model, or who can see what. It’s funny but with almost ALL these tools, the permissions model is where the pain is… And often, it’s not that it’s difficult, it’s just that it’s poorly communicated. You can’t see who can see what…

Other Tools Worth Considering?

Half way through the trials we kind of re-discovered Confluence, a commercial enterprise wiki with an impressive list of plugins (including Sharepoint connectors which may come in handy at some point).

And later I stumbled across Mike2.0 which is interesting in two ways. Firstly, it is attempting to share the knowledge about collaboration… and secondly, it attempts a shot at combining some best of breed open source tools into one suite. You can download omCollab which is WordPress, MediaWiki, phpBB and other tools all rolled into one seamless environment. It’s a great idea… it almost works… but there are seams (and it’s fun to install).

Some of the others we tinkered with are listed in my Delicious tag for collaboration .

The Difficulties of Evaluation Community Software

Because collaboration is almost impossible to simulate… the plan is/was to get as many teams actually using these tools on short length actual projects so that we could get reliable feedback about what works and what doesn’t. So, through a process of “walking about a lot” I met as many different teams at the university and badgered them into helping test the tools. We now have teams sharing content daily … and others tinkering at the edges. It’s a good mix and so far has been a damn sight more productive than attempting to evaluate what the organisation needs without people in the mix.

The next post will be about some of the features and bugs that we found along the way.

p.s This post would have been a lot longer, in fact it was, but somehow WordPress lost it and I’m still a bit grumpy about it… As it turned out, it’s probably a better blog post for being shorter…. still… grr!

PPPeople PPPowered

One of the stranger parts of the Collaborative Tools Project was that a few weeks into the job we accidentally landed a JISC funding grant to attempt to create something like Amazon’s “if you like this book – you’ll like these” but for people. The Jisc project is called PPPeople PPPowered and I will be blogging about it here.

The idea in itself isn’t that original, creating a browsable serendipity engine for people. Many people have tried to do this before. The basic wireframe of how it might look is shown below. What I am hoping is that I can simply make a reasonable job of assembling existing open-source tools to create something new, used and useful. A large part of my approach involves involving people in the project very early (like now) creating a site they could use every day and then augment that with mined data but also even have activities such as “Tag Yourself Day” so that we kick start the process at a human level rather than trying to achieve it all with technology.

At the moment I’m collecting tools that might be useful for working with peoples’ social media profile data, tools for reasoning about unstructured data and tools for working with large repositories like ePrints, Mendeley, CiteULike or Academia.edu AND tools for visualisation…  So if you have any suggestions, do  leave a comment.


Of course, one of the obvious visualisations would be something like a MentionMap network diagram (shown below).


… but then again, in many ways, although beautifully swooshy… it is something of a cliche isn’t it. What are the best methods for displaying connections, or possible connections between people I wonder?

Public Showcase and Engagement Blog Wiki Thing

Today’s Use Case for the Collaborative Tools Project is a difficult one to give an accurate title. It can be thought of as a site that promotes the work of a department or aims to attract a community of like minded people. It might have lots of media such as photos or videos from conferences or even lectures.

The teams I have that need this are…

  • The Sustainability Forum – who want to raise the awareness and debate around the University of York’s sustainability
  • The Philosophy Wiki – a Community of Practice about, er, philosophy (currently they are using MediaWiki)
  • Humanities Research – a cross departmental research department (currently using the WordPress service)
  • History of Art

An important part of this Use Case looks to engage potential students and impress funding bodies and attract collaborators. It is very much an “outreach site” and aspects of  social media marketing or Search Engine Optimisation (SEO) or being well ranked in Google might even come into play.

My first thoughts for providing service  this was WordPress…. and then the Philosophy team turned up and complicated things. Who’d have thought?

The challenge here is to give people what they want.. and what they tell me they want is…

  • Something that looks shit hot
  • Something that is very much “their look and feel”
  • Something that is the beginning of a niche community
  • Something that is theirs.

It’s a tough nut to crack.

At first I thought that a shared WordPress Multi-User environment, with a shared look and feel, although being easy to administer, might not be appropriate at all. It would be just “too corporate”. And WordPress is woeful at wiki integration and wiki thinking so it wouldn’t do for the philosophers at all.

But on the other hand, maintaining the upgrades on multiple installs of WordPress isn’t something I would look forward to doing.

I am struggling here to decide what is the best approach to providing great-looking, easy-to-use sites that broadly support self-promotion, blogging, community-building  and wiki working that are public-facing and look to engage the wider world in discussion or even content creation.

I currently am thinking of providing workshops, templates and guides to using Blogger, WordPress, PBWorks effectively and then make sure that we aggregate the items created centrally. This sort of gives people the “best of breed” service for a few pounds a month. They could even hire their own designers if the look and feel of free templates isn’t up to their very high specifications.

What would you do?

Project Workgroups

The next use case for the Collaborative Tools Project is Project Workgroups. The sort of online space where people can document their work (in a wiki), can tell each other what they’re working on (in a blog), share files and generally take the pulse of their team.

So far, I’ve avoided the all-out-files-based approach (like Sharepoint or Alfresco) because as I said earlier, I have a deep-seated and purely emotional fear of files (it’s their fault we’re in this mess dammit!)  in general and so we’ve been exploring what wikis and the like can provide.

I have been amazed at how poor many tools are at providing blogging features. It’s almost as if wikis really don’t want to be associated with their more popular cousin at all. Blogs have to be personal and authors need to feel a sense of ownership of them or else somehow they’re not really a blog. It’s just the way it is. And yet most “shared” blogging tools treat the blogs like documentation… uniform… impersonal…


A interesting and probably predictable part of trialling the wikis was the default permissions model… or who can see and edit what. In Elgg, the default state of say a blog post or a wiki page is that everyone logged in to the site can see it. This really scared the horses. Yes it is easy to change a wiki page’s permissions to “visible to the group only” but it was obvious to everyone around the table, or in this case, screen, that someone would forget and hell, or at least embarrassment would be let loose.

The flip-side of this “a bit too free and easy” situation is that when trailing SocialText, an enterprise wiki tool, I added people to their respective workspaces, Biology, Marketing, Maths, Librarians etc.. and people went away, worked hard, created content but because the default permissions model was that content was visible to members of this group, it meant that as a rule, the site felt uninhabited and lifeless.


By meeting peoples’ insecurities about content being private, or “good enough” and hiding content from other teams, everyone suffers… There can be no “happy accidents” or chance encounters when everyones’ office door is shut tight and sound-proofed.

At at this point it’s worth considering what is collaboration anyway? For many, the collaboration isn’t actually working together on say a bid document (in real or close to real time) it is just keeping an eye on other departments and teams and spotting overlaps and opportunities.

This “encouraging people to be open by default” is going to be a difficult nut to crack… not that people are naturally secretive but they often want to practice a bit before they jump on stage. One solution, that occurred quite by accident, is to start with an environment that is completely open…. with the promise that areas can be made more private later… This means that everyone gets to see the benefit (to them) of being able to nosey around other peoples’ areas and that can be more valuable (to them) than the need to be private and polished.

Collaborative Editing

One of the main requirements for the Collaborative Tools Project is collaborative document editing. A group of researchers, at York want to be able to work on a paper or a research bid document with researchers at other organisations. You’d think that by now this would be a solved problem wouldn’t you?  Some of the first GUI computers in the 1970’s created were designed to be used by two people, each with a mouse of their own, so surely by now collaboration should be as natural as a mouse gesture. It’s not.

The two most commonly used approaches for working collaboratively on documents are a. wikis where the document lives in one place online and b. emailing documents around lots of people. Both of these approaches are flawed.

The Problems With Emailing Documents Around

  • You receive feedback from seven people about the same typo
  • The latest version is sent to Jill who is on holiday and you have edits you want to make
  • Someone on the team doesn’t have the “right” version of Word
  • Someone just joining the team has no idea of “how we got here”
  • It’s difficult to add comments to text (without adding text to the document)
  • It’s difficult to know who added what. I’ve found most people aren’t comfortable with merging documents at all.

p.s If you are in the hell that is emailing documents around then CompareMyDocs (for merging) and CC Betty (for keeping track of who has the latest version) may help. I’ve also had a quick look at Alfesco (an open source replacement for MS Sharepoint) but deep down I feel that documents themselves are the root of problems so I keep looking for “document free” solutions to the whole collaborative editing itch.

The Problems With Wikis

  • The editing screens are often ugly and difficult to use. Nobody should have to learn wiki markup.
  • They often only work online, meaning you can’t edit the latest version on the train.
  • The interface, being browser-based is often slow or even worse “faulty” resulting in people losing their carefully crafted work.
  • Many wikis don’t handle concurrent saves very well, resulting in you losing other peoples’ carefully crafted work.

There are some interesting attempts at solving the collaboration problem, including Google Docs. Here’s a collaborative document about collaborative documents (shown below).


Google Docs (like most document editors, whether online or not) is poor at document navigation. Most of the document editors out there almost assume that you start at the beginning and then write until you’ve finished, whereas most of us jump around a document filling in the bits that we can. This jumping around (or what Jef Rasking called LEAPING ) is normally only ever done with the scrollbar which is woefully clumsy way of getting to the bit you want to edit.

Despite Google Docs being one of the most interesting tools, other alternatives have features worth exploring. I’ve been using Zoho editing tools recently, which have been integrated into a workgroup application called Huddle. Did you know they have an API meaning that you can embed a Google Docs quality editor in your web application?

Adobe Buzzword (apart from looking nicer) has the ability to add comments (or annotations) to the text. You can see the mess that Matthew and I got into in the Google Document (above) as we added our comments to the document. It took us a while to work out that we could assign colours to our comments and there isn’t a key (I don’t think) that keeps a track of who is which colour. I think annotation is as important as actual editing and is often overlooked in these sorts of tools.

One tool that tries to tackle annotation head on is Revizr. It’s not the clearest of interfaces, it could do with a Web2.0 lick and spit, but I like its thinking.


Etherpad, the “real time collaborative editing tool” is also worth a mention. Although it has a limited set of tools (this in itself may be a good thing) it’s nice because it is so immediate (see below). What I like most about Etherpad  is…

  • people are automatically assigned colours (which can be removed later)
  • there is a “chat room” (bottom right) so that you can discuss the changes you are making without them becoming part of the content.
  • I also like the fact that this chat room is time-ordered, whereas the document may “evolve” over time.


Etherpad has just been bought by Google, which probably means either Google Docs will inherit some of its features.

All of these tools seem to work better in different situations, or on different points on a collaboration lifecycle… which might look a bit like this… When you look at the process of putting a research document together, in really simple terms, there are distinct phases each which might need it’s own user interface.  For example, Etherpad works really well for documents around a page long but when the text is longer, people can be working on a completely different section and you have no idea that they are busy working away.


So far, I have yet to find a collaborative editing solution I’m completely convinced by. Tools that try to solve the problem by over computerifying the workflow end up too difficult for occasional users. Tools that totally mimic word processing applications are kind of starting from the wrong place. For me, I think all the opportunities for innovation are in the early and late stages of the collaboration lifecycle above, in collecting ideas (brainstorms etc),  shaping or outlining and finally annotation (or adding comments and content without changing it). We already have a plethora text editors that work well enough or work the way we want them to. I’m looking for tools or processes that support the whole process rather than just the middle bits.

This Month Is Collaboration Month

I’ve been inspired by OffMessage’s – A Little Every Day re-invigoration of his blogging and decided to follow suit. It’s time to eat my own dogfood again, so here goes.

Recently I’ve been working on the Collaborative Tools Project at the University of York which aims to improve online collaboration. It’s a fantastic mix of designing and providing tools, evangelizing Web2.0 concepts and hands-on training… I’m absolutely loving it!

So my plan is to share some of what I’ve been doing, thoughts, tools, results in a one blog post a day for a month format… or close enough anyway (don’t hold me to it). For me at least, it’s going to be Collaboration Month.

See you  next Monday…ish for day one which will be about the Use Cases we gathered.

I’m going to keep this below a Table of Contents as we go…

Use Cases

The Tool Trialled