By | June 20, 2015


Much work has been done in researching how users interact in collaborative environments. Most of this research lies in the computer-supported collaborative work (CSCW) field in examining how issues such as presence, awareness, and share views affect how people work together.

Presence is defined as the information is presented within the shared space among users that represents me as a user within the system. This can be minimalist and only include my name and perhaps some contact information, or it can be more high-fidelity and include a graphical representation (as is found in some 3D collaborative environments where avatars represent users in the shared space). Ultimately, presence allows a user to project himself into the shared space and provide other uses with a context of the current user.

Awareness is defined as how much information you have concerning others in the system. For example, in a face-to-face interaction, user A is aware of user B by noting where user B is, with what user B is interacting, facial expressions, non-verbal communication cues, etc.

Additionally, research has examined how users interact when sharing a common view of the shared space in contrast the how users interact when they have unique, independent views of the shared space. In a common view approach, all users within the collaborative environment share the same view/perspective of the artifact being examined; this approach is appropriate when it is critical that all users see the same information at the same time (used effectively in a mentor-training scenario [Wu, 2001]). Alternatively, with independent views, users are able to move about the shared space and examine different parts of the shared artifact and/or examine from different views; this approach is appropriate when users need to work on different parts of the shared space (used effectively in software development [Roth and Unger, 2000]).

These issues are relevant to configuration management and distributed software engineering because the shared space in a distributed software engineering environment is the source code, software architecture and design documents, test cases, and other software engineering artifacts. These artifacts are managed by the configuration management system, and in a collaborative software engineering environment, multiple users will share these artifacts and interact with each other concerning these documents.

Beyond what underlying algorithms and models a distributed collaborative software engineering system employs, ultimately the user must be presented with an interface in which to interact with the system. Getting the interface correct for collaboration can be problematic; users are loathe to give up their existing tools and single-user applications with which they have a high level of comfort, yet the benefits of collaborative systems bear examination and potential adoption if the users can adopt them and effectively use them.

Boyer et al. [1998] determined via interviews that team members do not need virtual environments that are overpowering and immersive. Rather, they seek tools that are passive, unobtrusive and provide the information that they need about their colleagues without creating unnecessary overhead in a new interface. The system proposed by Boyer et al. uses a progressive-scale model that goes from left to right; those users that you place on the left side of the window are “important” enough to allow them to interrupt your work and communicate with you; those in the middle allow for “bubble” popup messages that are small and easily ignored if you desire; and those on the right are blocked from interrupting you at all. The overall interface allows users to keep track of who else is in the collaborative system at the same time while still maintaining privacy and giving the user the power to control and avoid interruptions [Boyer et al. 1998].

Another study by Cheng et al [2004] show that meetings, email, software engineering process, and meetings can consume more than half of the average work day. Improved processes and better use of technology can help reduce this burden on development and allow more of the work day to be devoted to developing the software system. The authors make the case that if the Integrated Development Environment (IDE) is the central interface to the developer, why not integrate collaborative technologies that facilitate communication into IDEs. Booch and Brown refer to the intelligent integration of software development tools into the known interface with a positive net effect as “reducing fiction” in the development process; the authors go on to show that configuration management, screen sharing, and email and instant messaging would be useful collaborative tools to integrate into existing IDEs. Adding email and instant messaging to IDEs has the added benefit of automating source code (and requirements) change requests as well as automatically tracking version branching.

The study claims that many modern IDEs contain support for extensibility, but that these are simply additions to the user interface and run externally as scripts or “plug ins.” For such collaborative tools to truly be effectively integrated into the IDE, the collaborative tools and interfaces must be tightly coupled to the underlying structure of the system such that automation of configuration management and versioning.

Additionally, the study posits that modern collaboration within IDEs must include the flexibility to support passive peripheral awareness of others working on the system, support audio, video, and text interfaces, integrate with current/existing source control and error reporting/tracking systems, and allow for synchronous and asynchronous communication among team members. “Eclipse” is offered as an exemplar of an open-source IDE that exhibits many of the tools in the paper [Cheng et al., 2004]. This “Rear View Window” approach is passive in nature in that it does not obtrusively interrupt the developer – unlike telephone or instant messaging. The following figure shows the “Real View Window” approach in Eclipse:

The TeamSpace project [Geyer et al. 2001] seeks to provide services beyond traditional distributed conferencing; the goal of the system is to combine synchronous distributed conferencing with captured, annotated collaborative workspace so that participants can view the materials asynchronously. The theory behind the approach is derived from cognitive psychology’s “episodic memory” which states that we store and recall events based upon life experiences; leveraging from this, the system’s elements are all time-sensitive in that every event and captured content is related across time. Consequently, not only can users view the content of the collaboration hierarchically according to the contents that they seek, the user can also search across time (i.e. “I remember it happened somewhere near the end of the meeting”).

The system allows users to share and annotate PowerPoint presentations, agenda items (which can be “checked off” as the collaborative meeting progresses), action items (which can also be “checked off”), and provides for low-bandwidth audio and video to create the presence and awareness of other users [Geyer et al. 2001].

Fussell et al [2000] performed a recent study to examine the importance of having presence within the collaborative environment. In the experiment, a novice attempted to construct a complex mechanical device with the assistance of an at-a-distance mentor; the participants in the study were able to share a communication channel via voice and video, establishing a “virtual physical co-presence.” The study found that given complex tasks, remote users must have certain contextual cues in order for users to collaborate effectively. These “grounding” elements are:

• Establishing a joint attention focus: allow users to be sure that everyone involved is viewing the same common element within the system

• Monitor comprehension: use nonverbal communication and facial expressions to establish that everyone comprehends what was said/discussed

• Conversational efficiency: make it as easy as possible for users to communicate their intentions (i.e. allow gestures and constrain the conversation within the context of the system).

While this study examined assembling a physical device, the findings are also applicable in a distributed environment in which collaborators must establish a shared space in which to communicate about a common task [Fussell et al. 2000] – certainly applicable to distributed software engineering where multiple collaborating users must ensure that they are examining the same section of an artifact (and ensure that they are examining the same artifact!).

Koch [1995] reports on a collaborative multi-user editor entitled “IRIS.” While this system does utilize the near-deprecated model of a specialized/proprietary system, some interesting interface issues can be gleaned from the “IRIS” work. First is the concept of visualizing the hierarchy and structure of the document that is being shared among multiple users; this allows for users to easily identify who is currently working on each section/unit of a shared document. This “shared meta view” is central to the project’s goals and is achieved admirably. Also of interest is the systems ability to integrate the functionality and interface of single-user applications; this is absolutely critical in achieving widespread adoption of any collaborative system. Finally, the “IRIS” interface provides direct communication between authors so that the can pass messages to each other for clarification (or to request an author relinquish control of a section of the document so that another user may edit it) [Koch, 1995].

There is also a considerable amount of research in the area of agents and the ability to manage the complexity and sheer volume of information that users are flooded with. Moksha [Ramloll and Mariani, 1999] is a collaborative filtration system that allows users to specify their interest within the shared space at various points/parameters; the filtration agent then acts as an intermediary that selectively exposes the user to only those elements of the shared, collaborative space that the user has interest in. Many collaborative development systems can benefit from this model of filtering based upon individual users’ preferences, especially given the scope and size of many modern software system projects (tens of thousands of modules and millions of source lines of code).
[Schur et al. 1998] enumerate five critical elements from their research that define interface issues critical to collaborative systems. Successful CSCW systems will achieve the following:

• Social dialog: enables users to send and receive important concepts, thoughts, and ideas; this also enables the creation of “place” in which the collaborators interact.

• Provide framework: a collaborative environment may enable a more rapid application development (RAD) approach to accomplishing goals in that users can more rapidly cycle through their interactions and processes.

• Allow rapid context switching: the interface should allow users to author and then share changes/ideas rapidly without requiring a series of complex key or button inputs (i.e. make the system unobtrusive and easily navigable).

• Culture and trust dramatically affect adoption: realize that functionality along will not drive the adoption of a collaborative system – there must be an understanding by users as to what they will gain by using the new system.

• Timeliness: the interface and messages within the system must occur rapidly or users will get frustrated.

These are a sampling of the many HCI-related issues that have the potential to impact distributed software engineering. The common thread through all of these systems is that collaborating on a shared artifact is difficult unless these HCI-related issues are addressed.

Leave a Reply

Your email address will not be published. Required fields are marked *