In the CHIME virtual world, users interact with project artifacts by "walking around," where they potentially encounter other users' representations (avatars). While incidental encounters add a sense of realism to a virtual world, a potentially more useful application of this technology (which CHIME supports) is to allow a novice user to collaborate with an expert by finding his avatar and beginning a conversation. Geographically and temporally dispersed users are able to more easily gain context with work being performed elsewhere.
We use the term Groupspace to describe a persistent collaborative virtual space in which participants work. The participants may be geographically or temporally distributed, and they may be from different organizations cooperating on a common project (subcontractors on a defense contract, for example). Contained within the Groupspace are project artifacts as well as the tools used to create, modify, and maintain them. Artifacts may be organized and reorganized at will by project participants.
Central to the Groupspace concept is the idea that project artifacts continue to exist in their original form in their original repositories. This differs from traditional Software Development Environments (SDEs) (like Oz[1], SMILE[9], Desert[14], Sun NSE[17], Microsoft Visual C++[12]), as well as most traditional Groupware systems (like eRoom[8], TeamWave[18], and Orbit[11]) in which artifacts are under the strict control of the environment. In these systems, users are expected to access artifacts only through the development environment's cadre of tools or via COTS tools specially "wrapped" to work with the environment. In a Groupspace, artifacts continue to exist in their legacy databases, configuration management systems, bug tracking systems, rationale capture tools, etc. Additionally, Groupspaces may contain information generated within the space. A particular Groupspace may contain built-in tools and services to be used by participants, e.g. to add arbitrary annotations to particular artifacts, hold real-time chat sessions, add hypertext links on top of (and separate from) artifacts in the system, semi-automatically propagate knowledge among participants (in the manner of a recommender system [15]), etc.
Groupviews are multiuser, scalable user interfaces used to navigate and work in a Groupspace. In addition to allowing Groupspace participants to find and access relevant information quickly (as they might in a single user system, or a system in which they had no knowledge of other users' actions), Groupviews keep users informed about work being performed by fellow users. Groupviews build on research and commercial work in Multi-User Domains (MUDs) [3], chat systems [13], virtual environments [5], and 3d immersive games [7]. In a Groupview, a set of virtual environment rooms containing project artifacts is generated from the organization of the artifacts in the Groupspace. Rather than placing artifacts into these rooms arbitrarily or according to some external mapping mechanism (as in Promo[4], where the mapping from artifacts to rooms is created from a software process definition and cannot be modified by users without corresponding modification to the process), a Groupview generates the rooms and connections between the rooms from the artifacts themselves. For example, a software module might become a room in the Groupview, and the source files making up the module might be furnishings inside the room. Corridors might link the modules' room with rooms containing design documentation, test reports, and other artifacts related to the code. A core aspect of Groupviews is the ability to provide selective awareness of other users' actions. Participants' locations in the virtual environment, as well as their scope of interest (i.e. the project or projects they are currently involved in, portions of the system they are considered "expert" in, related documents they have recently read, written, or modified, etc.) are shared among other users. In the case of a Groupview involving multiple teams working on separate (but interrelated) portions of a project, it should be possible for users to "tune" awareness so they receive only information relevant to them and their work.
In a Software Immersion, the third component of the conceptual model underpinning CHIME, team members collaborate and perform individual tasks in a virtual space defined by the structure of the artifacts making up the software system. This builds in some respects on previous work done in the Software Visualization community (see [16]) in which visualizations of module interactions and interrelations are created. The primary difference here is that a Software Immersion is intended to be built semi-automatically, while most software visualizations are generated by human experts. When visualizations have been created by software, the generating software has been built to handle a certain small class of input (output from sorting algorithms for example as in [2]). When applied properly, Software Immersion can speed the learning curve faced by new project members. The architecture and organization of the system they are learning is no longer an abstract concept, it is something they can walk around in and inhabit. Software Immersion is similar in concept to emerging technology in use in Civil Engineering. In [6], the author shows quantitatively that new construction project members come up to speed faster and perform fewer mistakes when an immersive, virtual construction environment is built from the building design.
Groupviews attempt to help distributed teams work as a single unit by addressing awareness aspects of their collaboration. By utilizing virtual environment concepts, Groupviews provide a single shared workspace for all developers to inhabit. Even text-based Virtual Environments have been shown to be quite immersive to their users; see, for instance, the Carnegie Mellon study [10] in which users were shown to be addicted to their internet-based chat rooms and virtual environments. Awareness aspects of Groupviews help keep distributed team members up-to-date with activities being performed at other sites. By keeping users immersed in a single environment and aware of the work being performed at other sites, CHIME helps bind a distributed team together.
Software Immersion and Groupviews work together to help address some of the communications issues brought on by distribution. Users can walk through the virtual environment to find developers responsible for the software components they wish to discuss. Learning curves are shortened in two ways. First, since the organization of the virtual environment is created from the relationships among the software system modules, users quickly gain context on how the various components fit together. Secondly, communications are made easier because users can find other developers in the virtual environment based on modules they are responsible for.
Finally, Groupviews' selective awareness aspects can help with temporal distribution issues. By making information about what actions other team members have been performing recently, it becomes easier for a temporally dispersed set of developers to maintain a feeling of context with the actions being performed at remote sites.
We have performed an initial implementation of the CHIME model and are beginning experiments with it. In an initial experiment, we have created a Groupview from the Linux 2.0.36 kernel, which includes over 1.2 million lines of source code as well has many megabytes of supporting documentation (including design documentation, build instructions, informal README files, and web-based archives of the linux-kernel mailing list, used by kernel developers to discuss technical issues).