Instant Collaboration - Developing a Framework to Support New Patterns of Team-Cooperation
Authors: Alexander Schatten; David Pölz; Matthias Epheser
Year: 2007

Communication and collaboration is supported by a multitude of different (client) applications and backend systems. At the same time, new patterns of collaboration between knowledge workers arise: people want to communicate in-time, share resources, keep track of their issues and yet do not want to be unnecessarily disturbed in their concentration. We analyse several systems and approaches to support team-collaboration and finally introduce our understanding of “instant collaboration”. In our research we support first patterns with a middleware and client-side prototype. The system is built upon proven systems for (instant) messaging, communication and repositories, and suggest a system that allows support for new work-patterns, yet integrates seamlessly into existing IT and workgroup infrastructure and company policies. 1 MOTIVATION AND INTRODUCTION Knowledge workers want to communicate, they want to share files, and they want to keep track of their work. There are various tools and platforms available today that support many aspects of cooperation. Yet we believe that most systems currently available (commercial or open source) show significant weaknesses in terms of instant collaboration, meaning the rather ad-hoc forming of workgroups and supporting their resource-sharing patterns. We will analyse these issues in more depth in the next section. We started developing a new framework for instant collaboration, named JMellow which is part of the larger Peer Group research effort. JMellow was created as a research project, because there we see the need for an easy-to-set-up platform that allows instant communication and particularly resource exchange, annotation, discussion and versioning. JMellow is based on available and proven open-protocols and open source systems (like instant messaging solutions and repositories/content management systems). Yet we notice a resistance against installing new tools or introducing new protocols and proprietary systems: resistance to new tools typically comes either from management (in a corporate environment), from system administration (who has to install, maintain and integrate these new tools) or from the potential users themselves. Already Grudin pointed out, there should not be “a disparity between who does the work and who gets the benefit” (Grudin, 1988). Thus, it should integrate in existing user databases and content management systems (to please system administration), be easy to use and easy to administrate. Moreover it should use (if possible) the client applications people already use and only extend them where required. Eventually, traceability of work should be possible. Also, security issues and other policies (in the corporate environment)—typically associated with instant messaging (peer to peer) systems (Bhagyavati, 2005)—have to be addressed with our approach. This is hopefully the foundation to encourage management to consider instant collaboration tools as a next step in enhancing the efficiency of their knowledge workers. JMellow can be seen more as an instant collaboration middleware than a specific client-based system. Of course, we also developed client(s) in this project, but the system can be easily embedded in existing infrastructure. As knowledge workers should have access to the files of their workgroup everywhere and should be able to communicate with their workgroup members, we have chosen to make the web client the first client implementation. Others are following. Of course, JMellow can then be a simple file-sharing and instant messaging application. Workgroup-related performance metrics can be gained from the data that is exchanged over the JMellow platform. Hidden work flows can be found, communication structures be made obvious and project activities be measured. This paper is structured as follows: section 2 will outline some instant collaboration scenarios in detail, whereas section 3 explains our JMellow infrastructure in more detail. In section 4 we describe related work in this field. Section 5 gives a more in-depth description of the system architecture. Finally in section 6 we give conclusions and outlook for future research work. 2 INSTANT COLLABORATION A broad variety of applications are available on the market, or as open source software projects that address cooperation and communication. Mandviwalla et al. (Mandviwalla and Olfman, 1994) describe various needs and requirements of groups, and emphasise in detail, that different groups and collaboration scenarios have different requirements and it is impossible to deliver a generic groupware application that works out for everybody. Open design and customisation is necessary to support a broad range of applications. Thus, we see openness as a foundation of our project architecture, as will be described later on. Moreover, in our research work, we focus on what we call instant collaboration, which imposes new collaboration patterns that are not well supported by available software (see section 4). Daily work in distributed teams, show that beside communication, the most important feature is a solid way to exchange resources. Typical scenarios are sending files via email or instant messaging clients. These approaches have the disadvantage to be rather intrusive, as the workflow of the colleague is most likely being interrupted by this procedure. Moreover, resources are exchanged on a person-to-person level; meaning that significant bandwidth is wasted, if (as it is often done) many files are “broadcasted” to a larger community of coworkers, while many are probably not interested in this information, or not at this very moment interested in the information. Additional issues come up when documents are changed and sent back to the originator or to other persons. In a short time, documents run out of syncronisation. Other ways to share such resources typically are shared-file systems, or even better CVS or SVN repositories or other web-based file repositories like BSCW (BSCW, 2003). These systems allow a controlled storage of shared information, some also versioning. Hence such system can provide valuable help for group cooperation. However, some other disadvantages persist: to access these repositories, typically specific client software is needed or browser uploads have to be done. But more important, the repository interaction is not connected to communication and collaboration activities. We believe, that instant collaboration means communication and closely-connected other activities like file-sharing, annotation, access to other information systems, probably project management functionality and the like. Closely-connected means: ideally in the same client software, and with a usability that does encourage also less skilled users. Hence we focus at the first step on integration of communication (instant messaging) with file/resource-sharing, versioning and annotation. Further steps are outlined in section 6. But our concept is rather a communication/collaboration integration project, as we explicitly do not reinvent the wheel. So systems like SVN, JSR 170 repositories, content management systems or instant messaging middleware (Jabber, XMPP) are used as a basis and are integrated to support users in working with those valuable tools in a more productive way. 3 INSTANT COLLABORATION WITH JMELLOW AND INTEGRATION OF AVAILABLE SERVICES With JMellow, we want to demonstrate the feasibility of our instant collaboration concepts (fig. 1 shows a screenshot of the Open Laszlo/Flash client prototype). JMellow is platform-indepentent and will be provided under Apache open source licence (Apache Licence, 2006). Instant collaboration with JMellow is very straightforward. The user sees his or her colleagues ordered in groups in the JMellow client. As JMellow is primarily designed for usage within a closed infrastructure (Intranet), typically the user and group information is provided by the middleware (database). For our prototypical implementation, we use the Javabased Wildfire server (Wildfire Server, 2006). User and group information can be provided either from the Jabber-Server directly, or via an LDAP server. This is particularly handy in a corporate environment. The closed-group (intranet) infrastructure apFigure 1: Screenshot of the Flash (Open Laszlo) JMellow client. Contact list and documents are shared. In two chat windows personal and group chats are held. The Flash client even can preview certain types of documents (like the graphics in that case). proach is also beneficial in addressing issues with IMs on the corporate desktop (Bhagyavati, 2005) (security, policies. . . ). Usage as “open internet collaboration platform” is not the target audience. The consequence is that new colleagues immediately have a filled group/user list including contact information. This list of users can be used to chat via XMPP protocol (Jabber). It is noteworthy here, that the group/user structure also implicitly controls access control and visibility: i.e., if a user wants to chat with a person, she selects this person; if she wants to chat with a group she selects the group and automatically a group, chat is initiated. If a resource is shared with a group, implicitly all group members have access to this resource as long as they are assigned to this group. Using JMellow for resource management, it is avoided that large chunks of information are distributed via email, and the like. If a user wants to share—say, an Office document—he “drag-anddrops” it on the person or group. This document is then sent to the JMellow server (which is from a technical point of view a Jabber client) and stored in a proven repository. We experimented with a JCR-170 repository (Jackrabbit) (Nuescheler, 2006; Jackrabbit Content Repository, 2006), but currently use the Daisy (Daisy CMS, 2006) content management system. This is an important strategy, as we do not want to implement new systems where proven solutions are availa