WantedNeeded: UX Design for Collaboration 2.0

(First published on Boxes and Arrows on 12 March 2009)

No current software supports the full process of collaboration.

That’s a bold claim, and I hope that someone can prove me wrong.

This article is more of a “Working Towards …” position paper than the final word; written in the hope that the ensuing discussion will either bring to light some software of which I’m not aware, or motivate the right people to develop what’s needed.

There is plenty of hype about “Collaboration 2.0” at the moment, but the bugle is being blown too loudly, too soon. Take, for instance, the Enterprise Collaboration Panel at last year’s Office 2.0 Conference. Most of the discussion was really about communication rather than collaboration, with only a hint that beyond forming a social network (“putting the water cooler inside the computer”) there was still a lack of software that actually helped groups of people get the work done. What’s missing from the discussion is any formulation of what the process of collaboration entails; there’s no model from which collaborative applications could arise. If we can figure out a model then we in the UX community should be able to make a significant contribution to it.

I want to start this discussion by proposing a model for collaboration¹ that links the various elements of collaboration, comment on the so-called “collaboration software” currently available, and make some tentative suggestions about IA and UX requirements for a real collaboration platform.

A proposed model

Definition

Collaboration is a co-ordinated sequence of actions performed by members of a team in order to achieve a shared goal.

The main concepts in this definition are:

1. Collaboration is action-oriented. People must do something to collaborate. They may exchange ideas, arrange an event, write a report, lay bricks, or design some software. To collaborate is to act together and it is the combined set of actions that constitutes collaboration.
2. Collaboration is goal-oriented. The reason for working together is to achieve something. There is some purpose behind the actions: to create a web site, to build an office block, to support each other through grief, or some other human goal. The collaborators may have varying motivations, but the collaboration per se focuses on a goal that is shared.
3. Collaboration involves a team. No-one can collaborate alone. Collaboration requires a group of people working together. The team may be any size, may be geographically co-located or dispersed, membership may be voluntary or imposed, but there is at least some essence of being part of the team.
4. Collaboration is co-ordinated. That is, the team is working together in some sense. The co-ordination may follow some formal methodology, but can equally well be implicit and informal. There needs to be some sense at least that there are a number of things to be done, some sequences of actions, some allocation of tasks within the group, and some way to combine the contributions of different team members.

Components of collaboration

Any collaboration process involves interactions between six elements, as shown in the following diagram:

Figure 1. The basic components of collaboration

Artifacts	The Artifacts are the tangible objects relating to the collaboration. They include the outcomes of the process – the office block that progressively gets built, the web site that finally gets commissioned – as well as a variety of objects that were used along the way to promote, direct and record collaboration – such as design documents, project schedules, and meeting agendas.
Team	The Team element includes the collaborators and the interactions between them: Team membership and authorisation, inter-personal dynamics, personal identity, decision making processes, and communication.
Tasks	The Tasks element includes the list of things to be done in order to reach the goal, along with all the processes necessary to manage that list. How do tasks get formulated? How is their status recorded and tracked over time? How is the list prioritised and scheduled? How are tasks assigned to team members and how are personal ‘To Do’ lists presented?
Calendar	Most collaboration is extended across time, and consequently requires some degree of time-management: setting deadlines, milestones and task completion dates; scheduling team meetings; and keeping an historical record of events.
Actions	Team members perform Actions based on the Tasks assigned to them. The Actions might just involve searching or viewing the Artifacts, but more typically mean modifying the Artifacts in some way. There might also be some meta-Actions such as maintaining the Artifact repository, keeping a log of Actions and commenting on the Artifacts.
Resources	Resources enable the Team members to perform the Actions. They include physical equipment, money, external advice, and all manner of software (project management, Wiki, spreadsheet, and content management systems, among others).

The current state of collaborative software

There are three primary ways in which humans interact: conversations, transactions, and collaborations. There is plenty of software that enables conversation–email, VOIP, chat, IM, forums–and plenty of software for transactions–eBay, PayPal, internet banking, shopping carts. But what is available for collaboration?

There are many software applications that seek to enable collaboration². But let’s see what happens when they are evaluated under these three categories:

• The extent to which the software provides the required functional components (i.e. the boxes in Figure 1)
• The extent to which the software supports the interaction between those components (i.e. the lines in Figure 1)
• The usual criteria that apply to all software , such as ease of interaction, security, integration with other applications, and so on.

It is true that there are software packages for most of the individual components of collaboration:

1. Artifacts: we have software for maintaining and accessing a repository of digital Artifacts (e.g. any number of CMS applications–well-established ones like Documentum or Stellent, more recent one’s like Joomla! or any of the 925 others listed at The CMS Matrix), and we can easily construct databases for tracking the status of non-digital Artifacts.
2. Team: software for maintaining team membership, facilitating group-based decision support, and managing remote meetings (e.g. WebEx) and video conferencing. There is even some possibility that virtual worlds like Second Life may provide an effective environment for team interaction. In Growing Pains: Can Web 2.0 Evolve Into An Enterprise Technology?, Andy Dornan quotes a business manager as saying that “Second Life allows more user engagement than traditional video or phone conferencing.” I know of one company whose preliminary experiments with Second Life found that there was a more relaxed and open interaction via avatars than when a team interacted face-to-face.
3. Tasks: software for maintaining task lists (e.g. Jira, ScrumWorks); task dependencies and scheduling, Gantt Charts (Microsoft Project, @task); brainstorming; workflow and process modeling; and others.
4. Calendar: Microsoft Outlook (along with Microsoft Exchange Server so that the calendar is shared), Google Calendar, among other similar software.
5. Resources and Actions: Many software applications act as Resources for implementing diverse Actions. For instance, Wikis enable editing of shared documents, and there are any number of calculators, electronic dictionaries, encyclopedias, search engines, web design tools – software that team members might use as they do their work.

These ‘point’ solutions may address their targeted functions effectively and even showcase the core ideals of Web 2.0 – user-generated content and taxonomies, broad-based participation, software-as-a-service (SaaS), and rich user-interfaces within a web browser. But they can’t just be lumped together and called “Collaboration” (with or without the 2.0 suffix). If you buy into the definition and model described above, it should be clear that true collaboration software must go beyond a set of disconnected point solutions and reach for the broader goal of enabling the whole collaboration process.

A key shortcoming of current so-called “collaborative software” is that there is no compelling metaphor or unifying vocabulary. We have many of the necessary pieces, but they do not interact at either the backend or user interface levels.

Some major contenders

Computer-Supported Co-operative Work (CSCW) and Computer-Supported Collaboration (CSC)

CSCW and CSC both promised such systems, but where are the practical results? While these research areas from previous decades generated many novel and hopeful ideas, there seems to have been an overly academic orientation rather than much focus on software design. Although the theory made useful distinctions, such as the categorization of collaboration by time and space, the software that resulted from these efforts dealt more with communication and co-ordination than with real collaboration.

Google

Google offers an assortment of products that promote collaboration: Google Calendar, Google Apps, and more are promised. I was hoping that their acquisition of JotSpot in 2006 might result in a broader Wiki-based collaboration platform that unified those other offerings. But to date JotSpot has been silent. At this stage, Google’s offering is still an “assortment” rather than a clearly-conceived package.

Zoho

The Zoho suite encapsulates virtually all the point-solutions mentioned above. It includes the standard office tools (word processing, spreadsheet, presentations, email), remote conferencing, chat, meeting organizer, calendar, project management and a Wiki. All of that and more is delivered via a SaaS model through your web browser. Zoho is way ahead of any competition because of its unified user interface. However, there are still important aspects lacking in Zoho: not primarily additional modules but some key IA and UX characteristics that I outline below.

Microsoft

Perhaps the closest we have today is from Microsoft. Combine SharePoint, Outlook and the Office suite and this provides remarkably effective functionality for team management, scheduling meetings, communication and shared workspaces. Our organization makes heavy use of this combination, and it pushes teamwork and information sharing a long way ahead of where we once were. On the down-side, the Task management in that environment is quite simplistic, with little support for maintaining a complex task list, or prioritization, or comprehensive status reports. The Wiki facility shipped with SharePoint is very primitive³. Microsoft has implemented a “Collaboration 1.0” approach rather than “Collaboration 2.0”, by which I mean it requires a large degree of centralized control rather than drawing on the power of social networking. Of course, the content of email, announcements, uploaded documents, and so on is completely open to freedom of expression, but the constrained environment and heavy IT infrastructure make the system as a whole feels complex and unwieldy.

Multi-user editing

Perhaps something specific needs to be said about one type of so-called collaborative software – the type that enables multi-user editing of electronic documents. Most of these applications are primarily interested in version control: they maintain a repository of documents and control access to that repository. Authorized people can view documents and a subset of those can edit the documents. The software provides some process for giving each editor a copy of the document and when the changes have been made, the software merges the changes back into the master copy, while keeping some form of historical change log. Examples are clearspace and the various text-based code-management tools such as Subversion.

While revision control has an important role, it is a meager offering in terms of the extent of collaboration that it enables. In most cases, such applications assume that individuals work independently of each other. One user edits this part of the document and, as a quite separate task, another user may edit another part of the same document. Two people editing the same part of the document is treated as a problem, and typically the last person to submit changes trumps any previous changes.

A more significant level of collaboration requires the assumption that multiple people will be working together to edit the document simultaneously. That requires a single shared document rather than separate copies of a master document for each editor. See Wikipedia article for a list of such real-time collaborative editors.

XMPP (the Extensible Messaging and Presence Protocol) has extensions for both multi-user text editing and multi-user whiteboarding, so there is at least discussions about how such interaction can be standardized. But tools that use that protocol are few and far between.

The Challenge for IA and UX

There are many human and business activities mediated by computer systems where IA and UX practitioners have provided design guidance to make the interaction more effective. Given that collaboration is fundamentally about interacting effective to jointly achieve some goal, IA and UX can play an even more substantial role than usual.

So, what principles would you apply to collaboration software? Here are my suggestions:

1.      Build the user interface around a consistent, unifying metaphor.

• The metaphor should be goal-oriented. That is, a stated goal should take center-stage, with the Team, Tasks, Calendar, Resources, and Artifacts being other players in the drama.
• The user interface needs to enable and encourage interactions between collaborators. Perhaps the metaphor of a sport team would be effective.
•  A “portal”/dashboard pattern allows simple movement between team management, task list, calendar, documentation management and the like. That approach can collate the answers to core concerns like: What collaboration projects am I part of? What’s the current status of each? What’s on my To Do list?

2.      Build an open, extensible, modular framework: a collaboration platform rather than a single application.

• The scope of collaboration is too extensive to expect that a single vendor will be able to provide all the pieces. It is important to allow modules to be gathered from multiple sources and plugged into a shared framework.
• For instance, Jira might be the first choice for the maintaining the Task list, but the framework should allow that to be substituted with alternatives. Similarly, in a basic system there may be a limited reporting feature (e.g. to view the change history for the Artifact), but it should be possible to plug in a more substantial reporting application later on.
• Most importantly, it will be important to provide a standard API to the Artifact repository, so that any number of applications can view, add and modify Artifacts.

3.      Include at least the following functions “out of the box:”

• Team management: functions to define and authorize team members, and for individuals to update their personal profiles
• Task management: functions to add and prioritize tasks, allocate responsibilities to team members, and maintain current status
• Calendar management: all team members can add events to a single shared calendar
• Communication: integration with email, IM, and other technologies
• Meetings: ability to schedule a meeting and invite specific team members, publish an agenda, record notes and decisions from the meeting.

4.      The platform itself should maintain a collaboration history rather than leave that function to the plug-in components. All meetings, decisions, changes to Artifacts, Task status changes and other events are recorded in that history. The history should be displayed as a journal along a time-line as well as being exposed as a life-stream via RSS/Atom.

5.      Connect to other enterprise applications and data stores. A collaboration application will gain significant value if it can interact with existing databases, content management systems, security mechanisms, and if it can exchange data with other applications via some standard like Web Services.

6.      Implement all this as a Rich Internet Application. The complexity of interactions between team members who are potentially geographically scattered indicates the platform needs to be web-based. The complexity of interactions between users and the system indicates that the user interface needs to be very dynamic, with near-real-time synchronization between all concurrent users and a shared Artifact repository.

Conclusion

Maybe all I’ve done here is scratch an itch. But I hope that the itch is contagious.

Collaboration is an essential part of human endeavor and information technology is at a stage where it should be able to add value to collaboration in more ways that just connecting people in a social network. We have many web-based applications that address parts of the process, but who’s going to create the framework to bring it all together?

---

Footnotes

1 This model was first presented at BarCamp Sydney in August 2007.

2 Capterra’s Web Collaboration Software Directory lists “174 Solutions”. See also the Wikipedia article on collaborative software.

3 Lawrence Liu comments that the SharePoint Wiki is not intended to be best-of-breed, just something that “is sufficient for a very large percentage of our customer base”. Even that is wishful thinking, but fortunately, the guys at Atlassian have made a SharePoint Connector for Confluence that can easily replace the default SharePoint Wiki.