Patterns for Computer-Mediated Interaction

Till Schummer, Stephan Lukosch

• Publisher: Wiley
• Year: 2013
• ISBN:
  9781118725719
• Edition: 1
• Topic: Computer Science
• Subtopic: Object Oriented Programming
• Index: Computer Science

Written by well-respected experts, this how-to guide provides patterns for the design of human computer human interaction (HCHI). An increasing number of applications are currently designed for use by more than one user, eg: multi-player games, interactive web sites, mobile phones, collaborative learning systems, interactive workspaces and smart environments. In these areas there is a shift from (HCI) human computer interaction to (HCHI) human computer human interaction. The role of patterns in this movement is twofold: 1 st – patterns focus on the human user of the system; 2 nd – patterns assist developers in the development process of groupware applications.

Chapter 1

Introduction

New technologies have changed the ways in which people interact and collaborate over a distance. Users can stay connected over a network and practice new ways of collaborative working. Instead of working face-to-face most of the time, today many people collaborate with remote peers via the Internet. In professional work life, employees in distributed companies collaborate via distributed work groups, workers in distant parts of a virtual organization can form dynamic ad-hoc teams for a step in a production process, and people participate in virtual communities to increase their professional capabilities. This process is also visible in private life, where computer users increasingly participate in communities to make their lives easier or more interesting.

As a result, more and more applications are designed for use by more than one user. Domains in which this has become obvious are multi-player games, websites that foster interaction among visitors, applications for interaction between mobile users, systems that foster collaborative learning, interactive workspaces and smart environments, or peer-to-peer applications, to name only a few. In such areas we can see a shift in interest from human computer interaction to computer-mediated human interaction.

This book discusses how applications for supporting computer-mediated interaction or groupware applications can be built. A groupware application is a combination of software, hardware and social processes that supports groups in their interaction. The groupware thus is what mediates interaction in computer-mediated interaction.

We will use a pattern language to build such groupware systems. Pattern languages combine patterns from a specific application domain, and consist of patterns and the relations between these patterns. Patterns capture design knowledge and rationale so that a novice can make design decisions in the same way that experts would. By means of design patterns one can describe expert knowledge in the form of rules of thumb that helps to solve a problem in the application domain of the pattern language.

Depending on your role in the development process of a groupware system, you would make use of a pattern language in different ways:

— As a software developer, you would find guidance on how to implement groupware applications. The patterns would outline different functional components that need to be developed when approaching groupware-typical problems.

— As a user, the patterns would provide you with an idea on how the groupware applications might look and how social processes might change when groupware comes into play. Your role would probably require you to identify functional aspects of your envisioned groupware application and communicate them to the software developers. This can raise your level of participation and help to ensure that the solution fits into your context. In the case of high-level patterns, you might also be able to implement the pattern on your own by tailoring an existing groupware environment.

— Finally, as a student or researcher in the field of computer-supported collaborative work, you might use patterns to frame your research: a pattern language documents best practices that have evolved during recent years, and in the case of most patterns, provides you with links to research literature in which such practices have been discussed.

To complement the patterns, we will provide a common scenario that serves as an example of how to apply the pattern approach in a concrete case of groupware development. We have chosen the case of a distributed software development team that wants to make use of groupware technology to support the distributed development of a collaborative game engine better. We will tell the story of Paul Smith, who is the project leader of the collaborative game engine project. The story will tell you about how social interaction is intertwined with professional activities, and how Paul interacts with a global network of people to achieve his project’s goals.

The fact that we have selected collaborative software development does not, however, mean that the application of this book is restricted to that domain. As you will see in the scenarios, many of the issues that arise in the collaboration of distributed software developers are to the same degree relevant in other application domains such as distributed management, distributed product development, or distributed learning. You can consider this in the same way as an architect would understand the creation of houses: in our example we will build a metaphorical office building for software developers. But the skills required to create such a building can also be used to build a school or a building for car design engineers. It is you as end user who will introduce the domain-specific context of your group, while this book concentrates on groupware infrastructure.

1.1 Groupware: Systems that Support Computer-Mediated Interaction

A famous definition of the term groupware defines groupware systems as “intentional group processes plus software to support them” (Johnson-Lenz and Johnson-Lenz, 1981). This definition includes various aspects that we have to consider when designing groupware solutions:

— The core of the definition is the group. A group of users wants to interact using groupware. Naturally, the members of the group should play an important role in the design of groupware. The groupware design has the purpose of creating a solution that satisfies the user’s needs. End-user requirements therefore have to be the central issue during groupware design.

— The group interacts in an intentional group process. The interaction between people thus needs to play an important role in the design of any groupware solution. It has to become clear who interacts with whom. How strict the intentional group process is must be considered, ranging from unplanned interaction in virtual communities up to formally structured workflows in a distributed workgroup.

— The process is supported by software. The fact that software is mentioned third here emphasizes that the software itself should be a supportive facility to ease the interaction between people. The software should be adapted to the users’ needs to best fulfill its supportive role. At this point the software developer comes into play. As software supports the group process, the software developer should support the users in adapting or creating software that fits the process.

Compared to a focus on design, which has the goal of supporting the group in the manipulation of content, support for social group interaction needs a broader focus, that of the relationships between users. Tools for manipulation are in most cases used by one user (even in collaborative systems), so they affect the relationship between the user and shared artifacts. Social interaction, on the other hand, affects the relationships between users and needs to address issues like trust and privacy. In contrast to the design of tools for the manipulation of artifacts, which mainly affects human-computer interaction, the focus should thus be on human-computer-human interaction (HCHI). The design of tools therefore focuses on the interaction of the user with the artifact, and considers the human-human interaction as a marginal aspect.

To provide customized designs of groupware mechanisms, we have to make use of a design process that is flexible enough to adapt to the group’s needs. Experiences with the design of single user applications have already shown that many software development projects fail because of requirements inadequacies (Dorfman, 1997). In such cases, the customer is typically involved in the early stages of the project as a source of design requirements. This set of requirements is then implemented by the software developers and subsequently the customer assesses the result. However, if the requirements were not specified correctly, customers receive a product that does not match their needs. This means that requirements in the context of computer-mediated interaction must always address social aspects as well as technical aspects, which is why they are called socio-technical requirements.

Unfortunately, these socio-technical requirements are often less clear to the stakeholders involved in the development of groupware applications. Two factors make this part of groupware development difficult:

— While in single user tasks, such as word processing or image editing, only one actor interacts with an artifact, groupware needs to support the interaction of many users with each other. An interaction partner is thus not a technical, deterministic, artifact, but a non-deterministic human.

— Users are not as familiar with using these new opportunities for interaction compared with single-user applications.

The theory of socio-technical design views a community from two perspectives: the social system, including group processes, roles, and flow of information, and the technical system, which includes tools used within the community, such as IT infrastructure or buildings. From a socio-technical perspective these two systems are highly interrelated. A socio-technical perspective on groupware design has to be aware of three key aspects (Bikson and Eveland, 1996):

— It is difficult to predict the reciprocal effect of changes to either the social or the technical system.

— The process used to create the socio-technical system will affect the acceptance of the system.

— Both social and technical systems change over time.

The tools in the technical system, i.e. the software that supports intentional group processes (Johnson-Lenz and Johnson-Lenz, 1981), can be classified in many different ways. One popular way to classify groupware is to distinguish how it support groups. Teufel et al. (1995) introduced such a model and distinguish between three different main support functionalities:

1. Communication focuses on the information exchange between cooperating group members.

2. Coordination concentrates on coordinating group tasks.

3. Cooperation adds the ability to accomplish group goals to the above support functionalities.

As all main support functionalities start with the letter C, Borghoff and Schlichter (2000) later on called this approach 3C-classification. In their initial proposal Teufel et al. (1995) positioned the three main functionalities in a triangle to cluster groupware applications in system classes of common functionality, i.e. communication systems, workflow management systems, shared information spaces, and workgroup computing systems.

In contrast to the initial approach of Teufel et al. (1995), we propose a different approach. Figure 1.1 places well-known groupware applications in two-dimensional space. The vertical axis denotes the application’s support for coordination, while the horizontal axis is used to denote the degree of communication and cooperation that an application supports. This is possible because a higher degree of communication implies a lower degree of cooperation. By placing an application in this two-dimensional space, the individual degree of communication, coordination, and cooperation can be visualized much better for each of the application types.

Figure 1.1 Groupware applications in relation to their support of communication, coordination, and cooperation

In particular, we distinguish the following groupware applications in Figure 1.1:

— Audio/video conferencing tools all...

Table of contents

• Cover
• Half Title page
• Title page
• Copyright page
• Dedication
• Foreword
• Figure/Photo credits
• Chapter 1: Introduction
• Chapter 2: From Patterns to a Pattern-Oriented Development Process
• Chapter 3: Community Support
• Chapter 4: Group Support
• Chapter 5: Base Technology
• Chapter 6: Examples of Applying the Pattern Language
• Chapter 7: Epilogue
• Bibliography
• Index