Types of Groupware Applications
Back to top

As mentioned above, the variety of groupware applications is rivaled only by the number of discreet definitions of what groupware should do. Important concepts in differentiating types of groupware applications include workflow focused, communication focused, what-you-see-is-what-I-see (WYSIWIS), synchronous (real-time), and asynchronous (content repositories). Groupware applications may represent a combination of any or all of these criteria.

Scalia and Sackmary describe three categories of groupware, based on the level of complexity: email and electronic bulletin boards, computer conferences, and group decision support systems, which "promote discussion and analysis of problems and improve the speed and quality of the decision-making process" (1996). While these categories do highlight a clear hierarchy of groupware uses, actual groupware systems generally exhibit foggier boundaries.

Depending on the situation, the ideal mix of groupware dimensions can differ greatly. While synchronous groupware applications often attempt to replicate the dynamics of face-to-face communication (such as videoconferencing), the task-centered virtual environment may not require such a feature. Greenspan, Goldberg, Weimer, and Basso note that "being able to share maps, drawings, text, etc., is often more important than seeing the other's face" (2000, p. 252). Kraut, Gergle, and Fussell suggest that "the benefit of visual information comes from allowing collaborators to share the work area rather than from seeing one another" (2002, p. 31).

Furthermore, Gutwin and Greenberg note that with relaxed-WYSIWIS systems, in which the user sees a blend of both private and group view, maintaining awareness of others in the workspace can be a considerable problem (2002, p. 415). Gutwin, Roseman, and Greenberg explain this awareness problem with a basic rule of groupware present in much of the literature: "increasing individual control reduces the group focus inherent in WYSIWIS environments" (1996, p. 259).

Successful groupware applications require that the combination of these dimensions be tailored to the task to be completed in the CSCW environment. One-to-many communication may be well suited to one-way streaming video, while the group editing of a document demands the common focus of a strict WYSIWIS environment; an application supporting a coordination meeting among geographically-dispersed executives working with a common client may require a combination of videoconferencing and shared workspace features.

Components of Groupware Applications
Back to top

Lococo and Yen identify perhaps the most important element of collaborative systems, often overlooked as a functional component: people (1988, p. 93). The authors focus on both facilitators and decision makers as the common link among all other components of the groupware system. Many argue that, within the framework of groupware, users can and should serve in design roles as well.

Apart from the users of a system, the basic components of groupware applications include objects and concepts of a familiar variety. The basic regions of CSCW applications include: email, document management, workflow, information sharing, access to shared data sources, collaborative tools (Newning, 1997, p. 56), networking, communications tools, concurrent processing, windowing environments (Grudin, 1991), memos, databases, customer files (Lococo & Yen, 1998, p. 80), contact management utilities (Whittaker, Jones, & Terveen, 2002, p. 216), awareness tools such as miniature views and radar (Gutwin & Greenberg, 1998b, p. 516), shared whiteboards, document markup, discussion groups (Werbach, 2002), and public and private calendars (Kyng, 1991).

The Role of Groupware in Knowledge Management
Back to top

In terms of knowledge management, groupware fulfills a number of specific roles. Lotus Notes, the standard conception of a groupware application, supports two of these specific knowledge management roles; it enables both communication and group memory (Whittaker, 1996, p. 409). Groupware systems not only facilitate and provide a forum for organizational communication, but collect and store this communication as well. These dual roles represent Clases and Wehner's "most significant tasks" mentioned above, and reflect their "more modest approach" of CSCW, to "augment organizational memory" (2002, p. 42).

In addition to knowledge generation and storage, Gutwin and Greenberg note a general knowledge management role that all groupware systems should support, providing users with information about their collaborators (2002, p. 416). This is a more immediate, real-time need within a virtual environment, and Gutwin and Greenberg have pursued a great deal of research on awareness in virtual work environments that will be addressed later in this paper.

Groupware can also set the pace for knowledge workflow in an organization. Dix states that the ability for a groupware system to match the pace of the cooperative task is paramount to its success, and that "different tasks have different paces," and require appropriate means of notification (1997, p. 151). Similarly, groupware systems can also control communication and disruption: "the flip side to initiative is interruption. If other people or things have the responsibility for telling you when things happen, they may tell you when you least want them to!" (Dix, 1997, p. 151). A groupware solution should be able to manage pace and communication relative to the tasks it is employed to augment.

Additionally, groupware can be utilized to manage conflict. Kyng states that groupware is often responsible for identifying conflict, preserving a record of it until "procedures can be set up to handle it" (Kyng, 1991).

Structured conversational interaction such as that available in the threaded discussions of Lotus Notes (Whittaker, 1996, p. 410), can serve to facilitate conversation and bring out conflict, but they can also impede the conversation and knowledge generation:

Rather than facilitating conversation, attempts to maintain conversational focus by imposing a rigid topic structure may inhibit interaction. Providing prior topics may actually serve as a filter on conversations: if users are uncertain of the structure of the database, or its "rules of conduct", they may choose not to participate. (Whittaker, 1996, p. 416)

All of the roles described above also support coordination among members of an organization, which may be the most important facet of groupware for knowledge management. Effective groupware systems must add dimension to relationships among people in different locations, not merely attempt to replicate physical interaction. Such systems cultivate shared awareness, such as Lococo and Yen's "shared thoughts, shared media and shared models," (1998, p. 91), allowing users to:

These categories illustrate the importance of users taking active role in groupware for it success as a knowledge management solution. It has already been noted that people themselves may be the most important components of groupware systems. The philosophy driving knowledge management today holds that people are the assets, and must be encouraged to impart their value to others. It is no surprise that the issues facing knowledge workers and groupware developers often reflect psychological and sociological concerns.

Groupware Design and Implementation Issues
Back to top

CSCW is based on collective human activity and, as such, its use and value may be directly affected by group-interaction patterns, group-development processes, participant attitudes, and all the myriad social factors that are found in any work group. (Scalia & Sackmary, 1996)

As people can be considered the primary component of groupware systems, so can they be considered the genesis of most problems facing successful groupware implementation. Scalia and Sackmary shed light on a truism that can make or break an organization's adoption of a groupware solution for knowledge management. Wasserschaff and Bentley recognize that individual user buy-in is an important factor in system success and discuss "the need for groupware systems to recognize and support individual differences" and highlight "the tension in many existing systems which seek to support these differences only to the extent that they do not limit the system's ability to maintain a 'common context' for the group's work" (1997, p. 323).

Gronback, Kyng, and Morgensen (1993) state that "users do not make explicit distinctions between working in cooperative or individual 'modes', they just want to carry out their work," supporting their view that CSCW "should be provided as open building blocks that can be smoothly integrated with existing types of applications."

The statements above reflect the multitude of issues a designer must face in the development of groupware design and implementation. The factors at play that influence user perception of a groupware system can basically be approached in terms of awareness.

Awareness
Back to top

Dourish and Belotti state that "awareness information is always required to coordinate group activities, whatever the task domain" (1992, p. 107). CSCW is no exception; in the groupware environment, awareness is manifested in a number of ways: as workspace awareness, in feedthrough, and through shared context. Gutwin and Greenberg provide a description of the impact of awareness in a virtual environment versus face-to-face communication:

While staying aware of others is something that we take for granted in the everyday world, maintaining this awareness has proven to be difficult in real-time distributed systems where information resources are poor and interaction mechanisms are foreign. As a result, working together through a groupware system often seems inefficient and clumsy compared to face-to-face work. (2002, p. 411)

While perhaps clumsy, methods of working in successful groupware systems maximize what Gutwin and Greenberg call "workspace awareness," which they define as "the up-to-the-moment understanding of another person's interaction in the shared workspace"(2002, p. 417). By providing an understanding of what other users are doing and how the environment is changing, this awareness, Dourish and Belotti hold, provides users with the context for their own activities (1992, p. 107).

Workspace awareness is not an easy aspect of a groupware system to manage, as "how it happened" is rooted in the "occurrence of actions in time, implicitly noted and understood while they happen, but so hard to reconstruct afterwards" (Dix, 1997, p. 149). Because these reconstructions are difficult, constant workspace awareness is necessary. A constant stream of workspace awareness information is referred to as "feedthrough," or shared feedback. In addition to providing the user with information about the changes, decisions, and locations of other users, feedthrough helps users to understand that their own actions are visible as well.

Gutwin and Greenberg present an example of feedthrough in a shared workspace in which a graphical interface button reacts to one user's mouse behavior in manner that is visible to everyone in the workspace (1998, p. 211). In more complex tasks, such as browsing or selecting from a menu, only relevant information is transmitted to other users, such as the specific menu choice. The benefits of workspace awareness and feedthrough are best summed up by Gutwin and Greenberg in another paper: "Workspace awareness is used in collaboration to coordinate activity, to simplify verbal communication, to provide appropriate assistance, and to manage movement between individual and shared work" (1998b, p. 511).

Identity within a groupware system is another kind of awareness. First of all, identity makes the processes of workspace awareness and feedthrough possible by supplying actors for the actions. Secondly, where workspace awareness and feedthrough provide a running commentary of other users' actions, identity is often engaged as a means of determining what actions user can and cannot undertake in the group environment. This is called "role restriction."

While "role restriction" may seem like a feature that suppresses the activity of users, Dourish and Belotti frame it as a means of facilitating activity. "One of the efforts of role support... is to reduce uncertainty about the actions an individual might take, and hence provide greater awareness among participants of others' likely activities" (1992, p. 109).

Role restriction is also useful as a means of access control (Bentley, Appelt, Bushbach, et al., 1997), and can be an effective means of motivation as well. Identity implies accountability, which greatly impacts motivation, and user motivation is paramount to the success of a groupware system.

Challenges of Groupware Systems
Back to top

Grudin (1991) describes the general challenge of designing effective groupware:"...our effortless interactions with others make it easy to overlook the complexity of workplaces and the poorly understood nature of collaboration in general." This echoes Bardram's claim about learning "what we mean by cooperative work." The challenges facing groupware designers are diverse and many, and among these problems are many opportunities to explore Bardram's dilemma.

Gutwin and Greenberg identify three challenges to groupware designers in supporting awareness, deciding "what information to gather and distribute, how to present the information to the group, and when the information will be the most useful" (2002, p. 413). Additionally, they detail three problems in maintaining this necessary awareness:

First, the input and output devices used in groupware systems generate only a fraction of the perceptual information that is available in a face-to-face workspace. Second, a user's interaction with a computational workspace generates much less information than actions in a physical workspace. Third, groupware systems often do not present even the limited awareness information that is available to the system. (2002, p. 415).

Lococo and Yen identify a wholly organizational and hardware-based set of challenges:

The primary limitations of groupware include the organizational environment of the user, the existing architecture of the user's hardware system, the budgetary constraints of the organization, and the infrastructure in place in the locations that will be linked. (1998, p. 93)

Providing an idea of systems requirement issues facing a complex groupware implementation, Mills (1999) describes a set of groupware needs faced by the Defense Advanced Research Projects Agency (DARPA) to account for collaboration across heterogeneous bandwidth and devices, collaboration using natural modes of interaction, ready access to information affecting collaboration, collaboration without continuous activity, and the ability to evaluate effectiveness before deployment. These primary requirements seem almost prohibitive to the design of a system.

These three distinct sets of challenges are only the beginning. In designing for specific groupware environments, developers must also deal with the customization paradox that appears in much of the CSCW literature: the more a system is tailored to an individual, the less useful it is to the group, and vice versa (Kyng, 1991; Gutwin & Greenberg, 1998).

Causes of Groupware Success
Back to top

Despite the seemingly insurmountable challenges that oppose the designers of groupware systems, researchers have identified several factors that contribute to the success of groupware applications. Kline (2001) identified six clusters of user satisfaction issues (Ease of use, Training, Technical Support, Consultation, Work Needs Met, and System Capabilities) which can be viewed as a roadmap for building a user-centric system.

Additionally, Dix finds that several cultural factors can have a substantial impact on groupware success: a strong core of initial users, full integration of existing information, use of existing standards, and new standards that are simple and public (1997, p. 137).

Kyng feels it is imperative that users have a considerable hand in the design of the system, in which they "apply their competence in the application domain to the design process... moving from evaluating to creating" (1991).

Clases and Wehner prescribe that conflict be leveraged to maximize the flow of different perspectives throughout the groupware development process:

We hold that different perspectives (between software designers as well as between software designers and anticipated or actual actors at work) involved in design ... may become potential driving factors for the development of CSCW systems. (2002, p. 40)

To summarize, the strongest advice the authors offer to the designers of groupware is no surprise: focus on users and user needs. This advice is more difficult to manage in the context of the challenges addressed in the previous section.

Causes of Groupware Failure
Back to top

Obviously, groupware systems fail when they do not measure up to the previously discussed challenges. However, much of the CSCW literature deals with the specific reasons specific systems have failed.

Cockburn and Jones include among their identified causes of groupware failure situations that require too much effort on the part of the user, including the effort inherent in collaboration itself, the effort of meeting new system requirements, the effort imposed by reduced flexibility, and the effort imposed by difficult integration (1995). Implicating users reluctant to share information or have their work monitored by others, Lococo and Yen find that organizational culture plays a major role in the failure of groupware systems (1998, p. 94). The link between these two perspectives on groupware failure seems to be an expectation on the part of the user that CSCW should be entirely analogous to face-to-face communication. However, many of the conveniences offered by groupware rely on transactions unnecessary in physical workspaces. Those unwilling to provide information on their work activities or to extend themselves a little further to learn a new way of working will derail CSCW efforts. Newning's conception that groupware should concentrate on "improving intragroup communication rather than accelerating the pace of an individual's work," may be the approach necessary to combat this attitude.

The Future of Groupware
Back to top

Groupware and CSCW have been quietly shadowing the entire field of computer technology for the last few decades. Based on the rise of connectivity at the end of the 20th century and current trends in computing, it is likely the CSCW will remain in the spotlight and serve to unite some of the more disparate fields of computing in the future. It is conceivable that the concept of groupware will eclipse that of the Internet and Semantic Web as users become more able to define and interact within their own communities. Grudin states that intelligent agents are "often envisaged as furthering an individual's interests in group and organizational settings" (1991). This begs the question of which direction CSCW will take in the future: will groupware increase our awareness of the groups to which we belong or will groupware operate in the background of our interpersonal relationships, only interrupting us when permissions are needed or rules are violated?

In terms of traditional groupware and the immediate future, Lococo and Yen predict that as more and more systems are connected across the internet, that "users will be more demanding of the information available from this forum to enable them to be more productive and efficient as an individual and in teams" (1998, p. 100). Whittaker, Jones, & Terveen envision systems to exploit and manage contacts based on algorithms like one they have developed (2002, p. 224). Gutwin and Greenberg's research suggests that new and richer methods of maintaining awareness should be developed to increase the effectiveness of people interacting in virtual workspaces (1998b, p. 517).

References
Back to top

Bardram, Jakob. (1998). Designing for the dynamics of cooperative work activities. Computer Supported Cooperative Work '98 Proceedings, (pp. 89-98) New York: Association for Computing Machinery.

Bentley, R., Appelt, W., Busbach, U., et al. (1997). Basic support for cooperative work on the world wide web. International Journal of Human Computer Studies 46, 827-846.

Clases, Christopher, & Wehner, Theo. (2002). Steps across the border-cooperation, knowledge production, and systems design. Computer Supported Collaborative Work 11, 39-54.

Cockburn, Andy & Jones, Steve. (1995). Four principles of groupware design. Interacting with Computers 7(2), 195-210.

Dix, Alan. (1997). Challenges for cooperative work on the web: an analytical approach. Computer Supported Cooperative Work: The Journal of Collaborative Computing 6, 135­156.

Dourish, Paul, & Belotti, Victoria. (1992). Awareness and coordination in shared workspaces. Computer Supported Cooperative Work 92 Proceedings, (pp. 107-115) New York: Association for Computing Machinery.

Fussell, Susan R., Kraut, Robert E., & Seigel, Jane. (2000). Coordination of communication: effects of shared visual context on collaborative work. Computer Supported Cooperative Work '00 Proceedings (pp. 21-30) New York: Association for Computing Machinery.

Greenspan, Steve, Goldberg, David, Weimer, David, & Basso, Andrea. (2000). Interpersonal trust and common ground in electronically mediated communication. Computer Supported Cooperative Work '00 Proceedings, (pp. 251-260) New York: Association for Computing Machinery.

Gronback, Kaj, Kyng, Morten, & Mogensen, Preben. (1993). CSCW challenges: cooperative design in engineering projects. Communications of the ACM 36(4).

Grudin, Jonathan. (1994). Computer-supported cooperative work: its history and participation. IEEE Computer 27(5), 19-26.

Grudin, Jonathan. (1991). Introduction to special issue on collaborative computing. Communications of the ACM 34(12), 30-34.

Gutwin, Carl, & Greenberg, Saul. (2002.) A descriptive framework of workspace awareness for real-time groupware. Computer Supported Cooperative Work 11, 411-44.

Gutwin, Carl, & Greenberg, Saul. (1998). Design for individuals, design for groups: tradeoffs between power and workspace awareness. Computer Supported Cooperative Work'98 Proceedings, (pp. 207-116), New York: Association for Computing Machinery.

Gutwin, Carl, & Greenberg, Saul. (1998b.) Effects of awareness support on groupware usability. CHI '98 Proceedings, (pp. 511-518), New York: Association for Computing Machinery.

Gutwin, Carl, Roseman, Mark, & Greenberg, Saul. (1996). A usability study of awareness widgets in a shared workspace groupware system. Computer Supported Cooperative Work '96 Proceedings (pp. 258-267), New York: Association for Computing Machinery.

Kline, Theresa J.B. (2001). The groupware adoption scale: a measure of employee acceptance. Human Systems Management 20, 59-62.

Kraut, Robert E., Gergle, Darren, Fussell, Susan R. (2002). The use of visual information in shared visual workspaces: informing the development of virtual co-presence. Computer Supported Cooperative Work '02 Proceedings (pp. 31- 40), New York: Association for Computing Machinery.

Kyng, Morten. (1991). Designing for cooperation: cooperating in design. Communications of the ACM 34(12), 64.

Lococo, Anthony, & Yen, David C. (1998). Groupware: computer supported collaboration. Telematics and Informatics 15, 85-101.

Mills, Kevin, L. (1999). Introduction to the Electronic Symposium on Computer-Supported Cooperative Work. ACM Computing Surveys 31(2), 105.

Newning, Rod. (1997). Benefits of Groupware. Management Accounting 75(1), 56.

Scalia, Lynne M., & Sackmary, Benjamin. (1996). Groupware and computer supported cooperative work in the college classroom. Business Communication Quarterly 59(4).

Wasserschaff, Markus, & Bentley, Richard. (1997). Supporting cooperation through customization: the Tviews approach. Computer Supported Cooperative Work: The Journal of Collaborative Computing 6, 305-325.

Werbach, K. (2002). Bringing it all together: infrastructure for collaboration. Release 1.0. 20(2).

Whittaker, Steve, Jones, Quentin, & Terveen, Loren. (2002). Contact management: identifying contacts to support long-term communication. Computer Supported Cooperative Work '02 Proceedings, (pp. 216-225), New York: Association for Computing Machinery.

Whittaker, Steve. (1996.) Talking to strangers: an evaluation of the factors affecting electronic collaboration. Computer Supported Cooperative Work '96 Proceedings, (pp. 409-418), New York: Association for Computing Machinery.

postã„gäXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXcate 5 Sã„gäLºË!0»
ˆ‘cat @5 Sã„gäLºË!0»
ˆ‘ÿÿþaux TSURLLhttp://www.ischool.utexas.edu/~i385tkms/blog/archives/patrick/groupware.html