Environment Support for Cooperative Working

1

Environment Support for Cooperative Working

Leandro Navarro, Manel MedinaUniversitat Politècnica de Catalunya

Barcelona, [email protected]@ac.upc.es

Tom RoddenComputing Department,Lancaster University,

Lancaster LA1 4YR, [email protected]

The role of the computer in supporting the work of individuals is nowwidely accepted with the widespread application of tools to supportprofessional work. More recently, computer systems have becomingincreasingly used to support the work of groups as well as individuals.This trend has resulted in the emergence of a Computer SupportedCooperative Work(CSCW) [Ellis 91] as a research area.

Distribution and communication technology have a significant role toplay in the development of computer systems to support group work.This paper examines the issues surrounding the support of CSCWsystems and how this can be achieved by the development of a CSCWenvironment. This paper introduces an approach to the development of aCSCW environment and its implication for distributed systems. Thecomponents of a CSCW environment are introduced and a possiblearchitecture for the realisation of the environment model is presented.

1. Introduction

Cooperative work does not occur in isolation. Instead, the general picture is of manyinter-related work activities taking place within a common environment of sharedresources, people and information. Very often, the environment will be therepresentation of the organisation(s) within which the activities occur (e.g. thecompanies involved in the large engineering project or a University college offering acourse). In other words, COOPERATIVE WORKING NEEDS TO BE CONSIDERED IN

TERMS OF NUMEROUS RELATED ACTIVITIES INVOLVING THIS WORK OCCURRINGWITHIN AN ORGANISATIONAL ENVIRONMENT.

As CSCW applications become more widely available, it will become increasinglynecessary to focus on the relationship with their environment. Such an environmentshould be aimed at allowing a multiplicity of CSCW approaches and paradigms to co-exist.

CSCW application do not exist in isolation but become an integral part of the activitieswhich take place within the organisation they are embedded. If one considers thenature of group working in a large scale over a long time period, it becomes apparentthat any major activity typically involves the complex interaction of numerous sub-activities.

For example, the management of a large scale engineering project can be undertaken asa cooperative activity. The overall task may involve an on-going programme of sub-activities such as team progress meetings, the joint production of reports, monitoringand interviews as well as more ad-hoc, informal communication between projectmembers.

The various activities involved are inter-related in a variety of ways:

• People may be involved in many activities.

• They utilise common resources within a shared context (e.g. rooms,time, staff )

2

• They share common information. The information produced by oneactivity may be used in another. For example, a progress report of oneactivity may be presented in a separate meeting activity.

• They may have well-defined temporal relationships. For example,meetings occur at regular intervals with the production of reports inbetween.

There are also many differences between the activities. For example, some have welldefined goals and fixed deadlines while others are on-going. They may also utilisedifferent underlying communication technologies.

The current generation of CSCW applications provide models and mechanisms aimed atsupporting either a particular cooperative activity or class of activities. Each of thesesystems often postulate their own particular view of activities and how they should bestructured. These systems differ both in the formal basis of how they modelcooperation and how they represent the cooperation to users. Some exploit formalmodels based of either speech act theory or office procedures while others adopt aconsiderably less formal approach. Similarly, some systems use scripts to representcooperation while others exploit either network diagrams or production rules todescribe cooperation. The table below lists a number of significant CSCW systems andthe different techniques used to model and represent cooperative activities.

Research Project Cooperation Model Representation

Coordinator [Winograd 87] Formal ,Speech Act

Network

Information Lens [Malone 87] Semi-Formal Production Rules

Chaos [De Cindio 86] Formal,Speech Act

Network

Domino [Kreifelts 86] Formal ,Procedural Model

Script Based

Cosmos [Wilbur 88] Formal , AugmentedProcedure System

Script Based

Amigo [Danielson 86] Formal , AugmentedProcedure System

Script Based

Strudel [Sheperd 90] Semi-Formal Production Rules

Table 1 Cooperation models used by CSCW systems

2. A CSCW environment

These applications shown in table 1 are often unaware of the existence of otherapplications and provide few mechanisms for working in conjunction with otherapplications (Figure 1a). Given the strong interdependences across these variousworktasks this is a severe limitation of current CSCW systems.

The role of a CSCW support environment is to provide interoperability between avariety of CSCW applications ensuring that CSCW applications can work in harmonyrather than in isolation of each other (Figure 1b).

3

CSCW

Application

CSCWApplication

CSCW

ApplicationCSCW

Application

CSCW

Application

CSCW

Application

CSCW

Application

CSCW

Application

CSCW

Application

CSCW

Application

CSCW

Application

CSCWApplication

CSCWApplication

Figure 1a: Independant CSCW Applications

Figure 1b: CSCW applications in an Environment

CSCWENVIRONMENT

?

?

?

?

A number of recent systems have considered the need for providing support servicesfor CSCW applications. Most notably MMconf [Crowley 90] and Rendezvous[Patterson 90]. However this systems have concentrated on the development ofinfrastructures to support features of various real-time CSCW applications. In addition,researchers have demonstrated how CSCW applications could utilise different OSIstandards to provide infrastructure support [Prinz 91].

The work presented here differs from previous work in that the environment wishes toprovide facilities to allow an understanding of the cooperation involving differentCSCW applications to be shared. In particular, what is considered within this paper isan architecture for a computer based environment which provides a range of supportingservices for establishing and running different activities. These services may be realisedas an extension of the existing services provided by both OSI and ODP platforms.Environment support services might include:

Information Sharing

• Sharing resources between activities

• Providing a common base for shared information

• Mechanisms and services for the access & exchange of informationbetween CSCW and non-CSCW applications

Activity Support

• Facilities to record those interested in activities

• Facilities to allow the progress of activities to be monitored

Organisational Support

• Maintaining a knowledge base of people, resources and organisationalprocedures.

• Mechanisms for modelling organisations.

• Mechanisms for recording the responsibility for activities

General Support Facilities

• Security and accounting mechanisms.

• External services for application developers

• Interface mechanisms for easy integration with external services, forexample, OSI facilities

4

It is our believe that the development of a cooperative support environment within anorganisational context is an important issue for cooperative work technology. Thispaper considers the issues central to the development of this environment and postulatesa possible architecture which allows a CSCW environment to be realised.

A Cooperation Environment should provide some degree of transparency 1to facilitatepeople cooperating from different coordinates, distributed at different locations of amultidimensional space whose coordinates could be measured in organizational,temporal, linguistic, cultural,.. even physical units.

As we have seen group working on a large scale and over a long period, involves thecomplex interaction of numerous sub-activities. The current generation of CSCWapplications are closed and provide little support for integration . A significant role of aCooperative Environment is to provide inter-operability between a variety ofcooperative applications ensuring that CSCW applications can work in harmony ratherthan in isolation of each other.

To achieve this inter-operability between cooperative systems will require thedevelopment of "open" CSCW systems. These systems will be open to both integrationwith other CSCW systems and the augmentation of these systems by both users anddevelopers. It is our belief that open Cooperative Systems will need to be based on anEnvironment which gives support for the idealization, realization and usage processesof cooperative applications. The role of this environment is to abstract the complexity ofthe 'Real Cooperative World' surrounding a certain application. At the same time,applications, as opaque objects within the environment, may look homogeneous in theiruse of the environment at any point of the modelling process.

It is important that the development of Open cooperative systems and their associatedenvironment should be based on present and future international standards. In thisdirection, the Environment presented here is considered in terms of the emerging ODPReference Model [ODP Ref] and the upper layer protocols of OSI [OSI Ref] .

2.1 The role of transparency

A major mechanism to be applied in the development of a cooperative environment isthat of transparency. Recent work on distributed systems has clarified the meaning ofthe term transparency [ANSA 89] . Distribution transparency is seen as a collectivename for the masking out of various features of a distributed computation. Each ofthese features can be thought of as an additional dimension of transparency.

A significant aim of a cooperative environment is to define a distributed architecture thatprovides several degrees of transparency, to hide some dimensions that are unnecessaryfor the cooperative activity and makes the system more complex. However, in certaincircumstances , applications may need to be aware of what is going on. Given theflexibility of CSCW systems is important that the concept of selective transparency isapplied within cooperative environments [Rodden 91] and that the degree oftransparency can be selected and modified.

A number of different transparencies are important to the development of a cooperativeenvironment. The transparencies central to the development of an open cooperativeenvironment are briefly listed in the table over:-

1 This is also called "selective transparency".

5

Transparency Central Issue Result of transparency

organization The organizations to whichobjects are members

Objects do not have to deal withdifferences between organizations

time The time dependence betweencooperating users, i.e

synchronous vs asynchronouscooperation

System design independent ofform of interaction

location Local or remote localization ofobjects

Objects unaware of the locationof other objects

domain The interest on a small subset ofobjects, those pertaining to a

domain

Objects are unaware of theexistence of other unrelated

objects

view The application of different viewsper user. For example,

WYSIWIS

Users are unaware of the differentviews of other users

activity The coordination and complexityof cooperative activities

Objects are unaware of themechanism for running activities

involving the coordination ofseveral objects

security Security concerns Objects are unaware of theapplication of the security policy

Table 2 Different forms of transparency for CSCW

The definition and maintenance of these transparencies is a central feature of acooperative environment. The set of transforms outlined above represent only some ofthe salient features of cooperative working where the use of selective transparencywithin a cooperative environment may be useful.

2.2 A real world approach to modelling

Our approach to understanding the nature of our open environment is to use a 'real-world' metaphor. Essentially, the metaphor shows an organization as a set of roomsconnected by doors, through which people move and within which they work (figure2). People are always able to communicate in an unstructured way. This unstructuredinteraction may be augmented by additional communication tools and morespecialised/structured communication facilities.

Figure 2 A cooperative rooms setting

Inside a room within our example world, people are aware of other people and haveopen channels through which they can communicate. Three important points emergefrom this arrangement.

• Informal communication is always possible via these channels.

6

• All work, individual as well as explicitly collaborative, takes place in some spaceand all work is potentially collaborative!

• Structured activities2 can be added/supported either as more specialised rooms or

as tools within rooms.

This 'Real-World Metaphor' acts as a conceptual driving point for the work of theenvironment, allowing a wide diversity of cooperative situations to be consider. In ourapproach to developing the environment models are constructed by abstraction of theproperties common to all possible distributed systems3 and the need to be able toexpress the requirements relevant to distributed processing of all possible enterprises4.This process is represented in figure 3.

All PossibleEnterprises

Choice

Open Cooperation Reference Model

(OC-RM)

Requirements

All possibleCooperative Systems

All possibleOpen Cooperative

Systems (OCS)

ModelsAbstractionDescription

Requirements Prescription

SpecificEnvironment Components

Open Cooperation Reference Model

(OC-RM)

All possibleOpen CooperativeSystems (OCS)

Environment conforming Open Coop. Systems

Choice

Prescription

Prescription

Figure 3 The modeling process for an Open Cooperative Environment

The first step is to consider the requirements for the set of models which we havebriefly outlined in the previous section. These requirements have resulted from a rangeof ongoing activities within the Mocca group. These requirements help to describe eachmodel, and to discover the functionality of the Environment. This is an ongoingprocess with the developing Environment prescribing how Cooperative Applicationsshould behave to be Open (i.e. restrictions we wish to impose to applications "living"in the Environment).

After we had defined the functionality and the models in the Environment, we would

choose (and specify) the set of Specific Components (and operations) that will be part5

of our MOCCA Environment Architecture. This will prescribe how 'Open Cooperative

Systems'6 should be constructed. Conformance of components can be measured at

'reference points'7.

2Main interest in projects such as AMIGO Advanced, Chaos, Domino and Cosmos.

3Transparency, separation, location, cooperation, concurrence, heterogeneous, fault tolerance,isolation, incremental change, autonomy, time, ordering, performance.

4These are descriptive models: all examples of enterprises can be represented by that model. Themodel merely describes what the salient properties of a model should be.

5Common Components (and functions) for the Environment can be chosen by consensus. Someactivities could need specific components (e.g. a document store for Joint Editing).

6OCS: Set of CSCW applications cooperating in an organizational setting.

7Reference point: An interaction point declared in a standard as a point at which behaviour maybe observed for the purposes of conformance testing. There are four classes that allow testing: at aprogrammatic interface (C binding of SQL), at a human computer interface (graphics standard), ata point of interconnection (OSI standards), of an external physical storage medium (informationinterchange standards).

7

3. The General Mocca Architecture

The general Mocca architecture provides a set of loosely connected managers whichprovide appropriate portions of cooperative support. These managers are intended toabstract over the services provided by existing OSI and ODP platforms is a simple andversatile manner. The set of managers within Mocca is intended to be extensible so thata Mocca platform which realised this architecture could readily evolve as the nature ofthe cooperative work being supported altered.

Two of the managers currently identified by the Mocca environment are aimed atsupporting the manipulation and storage or information. Most cooperation involves thesharing of information which often provides a focal point for the cooperation takingplace. Subsequently a central repository, an information store, for shared informationas in environment places a significant role is a cooperative environment. This isaugmented within a cooperative environment by the provision of an organisationaldatabase which allows organisational information to be shared.

In addition to the static organisational knowledge held within the organisationknowledge base active support within the environment is provided by three activecomponents, the domain manager, the activity manager and the security manager. Thegeneral architecture is presented in figure 4.

Loosely Coupled managers.

A set of managers defines a

specific instance of a

cooperative envitonment.

Organizational

Database

Domain

ManagerActivity

Manager

Security

Manager

Information

Store

OSI / ODP Computational Platform

User

access

User

access

XX

Managers

Application living

in the EnvironmentUser

access

Figure 4 The Mocca cooperative architecture

This architecture provides a set of optional interfaces for an application within theenvironment. This allows an application to maintain as many different ports asmanagers wants to interact with. The more ports are used, the more environment awareis the application. The extreme situation would be an application without any port toany manager: this application will have to contact to other objects. That service isprovided by the domain manager, and supervised by the security manager.

The environment should allow services to be easily added and removed from theenvironment as future additional common services are identified.Several initial servicescentral to a cooperative environment have been identified: an organisational database, adomain manager, an activity manager, a security manager, and an information store.These managers are briefly described in the following sections.

3.1 The Domain Manager

The Domain Manager. is an object to which all objects in the distributed environmenthave a connection (is a well known object/service). It has key importance during the

8

configuration phase of distributed activities. It receives requests from objects requestingservices (connection to other objects), it consults the Organizational Database andestablishes connections between objects (working phase). It can also receives requestsfrom Domain Managers pertaining to different organizations to set-up inter-organizational domains or activities.

One of the services offered by the Domain Manager is the management of domainswhich are abstraction over sets of objects within the environment. Objects can begrouped into domains to simplify the set of alternative objects available. This can alsobe used to separate/isolate objects with the same aspect (operations) but different kindof services. Domains will be structured in an acyclic graph (no loops, but a node canhave more than one father).

To support a concrete activity it should be decomposed in terms of objects available inthe environment and the application specific objects. A domain could be defined for thisactivity, and objects put in that domain. In the configuration phase, a domain (or a partof the domain tree) is consulted to look for services (objects) registered or visible.Requests are made to the Domain Manager and, after consulting the OrganizationalDatabase, and authentifying the objects (that is the job of the Security Manager),connections will be established and objects will be able to carry on the activity bythemselves, without any intervention from the Domain Manager. It is expected that thedomain manager will make us of underlying directory services such as those offered byX500.

3.2 The Activity Manager

A central objective of the MOCCA work is to allow some degree of integration acrossdifferent models of cooperative work and applications based upon those differentmodels. This suggests that:

• Applications based on particular models should be easily integrated into theEnvironment (to use/interact with the Environment and other entities). Thisrequires something to translate from particular mechanisms to mechanismssupported by the Environment.

• Activities and/or applications can be integrated (composed objects) to form newactivities. This means that we also need to provide some mechanism whichwill allow different entities to inform each other when certain conditions haveoccured.

Activities can be composed objects

Application (Activity)

Adaptor to Environment

Environment-conforming Activity

Figure 5 the composition of activities within Mocca

The Activity Manager allows activities generated or supported within an application tobe registered outwith the application in the MOCCA Environment. Other applicationsinterested in that activity can also register their interest in the status of that activity withthe Activity Manager. For example, an application may wish to publicise that it isinvolved in the development of an production plan for a bridge. To do so anapplication would construct an activity entry in the Activity Manager from a set ofcentral services in the Environment.

We have assumed that: activities are modelled as objects, and that the Activity Managermanages dynamic information: references to running activities, while the OrganizationalDatabase manages more static information: it contains Activity Templates andorganizational restrictions to instances of those activities.

9

Four items are important within the environment view of activities:

• defining activity templates (optional)

• instantiating an activity

• running an activity (updating the status)

• terminating an activity when ended

Defining activity templates implies that an activity template is defined and registered inthe Organizational Database. This activity template contains the information that entitiesin the Environment should know about the activity. Registration in the OrganizationalDatabase means that an Activity Template is registered in the context of the organization(who can instantiate and use, what is the cost of running an activity, and any otherorganizational restriction to activity instances of that activity template).

More dynamic activities will not have an activity template object registered in theOrganisational Database. An entry representing the activity instance will be createddynamically in the Activity Manager by the application responsible for that activity.

3.2.1 Events

Events are primarily produced and consumed by activities and event handling is one ofthe major responsibilities of the Activity Manager. It acts as an event router. Activityinstances are registered in the AM and entities can browse and get information about theevents that an activity can produce. An object can register interest on a subset of eventsgenerated by activities.

Events are items composed of one or several attributes that convey specific informationabout changes in the state of objects, but they are opaque for the Activity Manager.

The AM can send an event to those objects that have expressed interest or an activitycan send an event to a set of objects or domains (subject to organizational and securityrestrictions).

Event processing and filtering can be seen as convenient. This means that entities canprovide rules or scripts to process/filter events. These are event handler objects. TheAM routes events to them, events are processed there, and new events may begenerated. For example, the event "ProjectFinished" is generated by a particular eventhandler object when all employees have finished or the time is gone, and the projectmanager has filled the administrative form. Using the concept of specialization, the AMcan be specialized in the future, supporting new and more powerful functionality.

3.3 The Information Store

The Information Store provides common storage services to the objects living in theenvironment. It should be able to store information elements, structures, rules andcomplex objects. Requirements for concurrent access and quality (e.g. accuracy,reliability, consistency, availability, lifetime, etc.) will be diverse ranging from criticallong term data, to short term state information data.

One key function of this store is to provide inter-operability among different objects bysharing a common service access point and information representation. The service willbe used not only by Managers, but also by application related objects.

The diversity of requirements may lead to the decomposition of a single InformationStore (useful for modelling purposes) into several more specialised Information Stores.That may or may not be visible for users of the Information Store service, providing theInformation Store a certain degree of transparency to that matter.

3.4 The Organisational Database

The organisational database contains information about the organisation in which theenvironment is set. The organisational database represents an organisation in terms of

10

the resources used within it, the employees working for it, the roles they play and theorganisational procedures and policy exploited within the organisation.

The organisational database also captures a number of organisational relationships.Formal and informal organisational relationships are represented within the database.For example, formal relationships organisational relationships of the form "ian is tom'sboss" and informal relationships of the form "tom manages system configuration" canboth be represented. The organisational database will allow applications to exploit theserelationships to encode the assignment of responsibility within an organisation.

The organisational database allows information regarding organisation membersexpertise and interests to be stored and queried by systems. This information will oftenmap onto underlying structures and services such as those provided by X500. Finally,the organisational database allows organisational roles and policy to be stored andaccessed by a number of different cooperative systems.

3.5 Security Manager

One important concern in a inter-organizational-distributed-cooperative environment issecurity. The security manager object groups all matters related to security.

Security is concerned with ensuring that the resources of the system are available tothose who are allowed to use and/or access them, and are not available to others,including non-intentional access.

Security requires mechanisms and policy to guarantee the integrity and confidentialityof resources.

Organizations are responsible for describing a security policy which allows measures tobe taken against possible threats to the security of the distributed system (e.g.unauthorized disclosure, contamination, misuse of resources, repudiation, denial ofservice). A security policy will consists of:

• Set of criteria for the provision of security services.

• Description of requirements for security

• Identify measures to be taken which will enable those requirements to berealized.

The security policy must identify:

• elements: human users, groups of users, accounting groups, auditing groups,information processing classes requiring protection, etc.

• requirements for authentication of elements

• requirements for control of interaction between elements

And must also define:

• a security authority domain to which policy is applied and control ofrelationships with elements outside its domain.

4. A Simple Example

Let us consider the case of a seminar or lecture room with a white laminated boardwhich can be written by anyone in the room. Within the room there will be a number ofcooperating users. This scenario has been addressed by a number of CSCW systemsincluding CoLab [Stefik 87] and Project NICK [Cook 87] and provides a usefulconcept demonstrator for the Mocca architecture.

In our example whiteboard each cooperating user has a number of mechanisms forinteracting with the wall.

Inspection mechanisms View which allows them to see on the wall. Views allowusers to focus on particular parts of the wall

11

Alteration mechanisms Pen which allows users to write on the wall

Duster which allows them to wipe the wall clear

Pointer for indicating elements on the wall

This is the drawing

surface for user A.

Here is where

user B writes

Any object can be

attached to the wall

File Edit

Sample

document

Figure 6 A shared whiteboard

The whiteboard can contain more than simple drawings or text (figure 6). It can bemodelled as a surface composed of elements and each user with has a pen has the rightto draw or to put things in the wall. To avoid the problem of concurrent access, eachuser owns a transparent overlay layer which is coincident with is his view. This meansthat no user can "compete" with each other: they work at different layers. Concurrenceand ownership are guarantied.

These views are registered (they have a name) on a whiteboard object. This lets users tochoose a common sub-area of the wall and work there together. Sub-areas can overlapand sub-areas can be further subdivided.

User UserUser

DomainManager

UserInterface

OrganizationalDatabase

UserInterface

UserInterface

White wall

DusterPointer

PenPen

Configurationphase

User UserUser

UserInterface

OrganizationalDatabase

UserInterface

UserInterface

White wall

DusterPointer

PenPen

Workingphase

DomainManager

Before configuration After Configuration

Figure 7 Environment configuration for the drawing Surface

The logical model (figure 7) shows the role of pen duster and pointer objects. In theconfiguration phase resources are assigned and organizational restrictions implementedby the domain manager. In addition, some wall configuration options can be negotiatedby the domain manager (for example, overlapping of transparencies, maximum numberof simultaneous users, etc..)

After the configuration phase, user-access objects have a direct connection to theobjects that have been assigned to them. If some object wants to change hisconfiguration in the "Working phase", the Domain Manager will be contacted. Thatmeans that the Domain Manager object is a well-known service: all objects have alwaysa connection to it.

The Whiteboard object is concerned with the management of the group tasks associatedwith interaction with the shared wall surface. If it was felt that a whiteboard was a

12

generically useful service within the environment it could be incorporated into the set ofmanagers within the environment.

Pointer, duster and pen objects realise the interaction mechanisms with white wallobjects. They have been modelled as objects to reflect that the number can be limitedand that they are assigned in the configuration phase by the Domain Manager incooperation with the Organizational Database.

Another alternative would be not to model pointer, duster and pen as objects. Then wewill have rights (to point, erase and paint) which will be negotiated during theconfiguration phase, and user access objects will send the appropriate messages(invocation of the operations) to the white wall object.

In the last alternative, the user access object is acting in the role of pointer, duster orpen (or any combination of them). We would say that the user access object iscompatible with those objects: it can act in the role of any of them.

If the activity could be of interest to other people or objects in the environment, then itmay be published in the Activity Manager in the form of an activity instance entry.Other interested objects may use that information to different purposes: to becomepassive participants, to be notified when the activity finishes (to try to grab theresources being used), etc.

If the activity is considered relevant and reusable in the future, someone may apply tothe organisational database to register an activity template based in the current activityinstance. This activity template will contain some information that will simplify futureactivity instantiations of that activity.

In this example, the Security Manager has not been used explicitly, but it has beenmonitoring and enforcing the security policy of the organisation where this activity tookplace. This is an example of transparency: the security policy has been followedwithout any concern from the application. The application has delegated thatfunctionality to the environment (the Security Manager provides that functionality).

5. Summary and Conclusions

This paper has presented an approach to developing an environment for cooperatingworking which provides an abstraction over existing OSI and ODP services andplatforms. A modelling approach based on a real world metaphor is used as part of theenvironment development . The environment is designed to implement a number ofdistinct transparency which extend the existing concept of transparency withindistributed systems.

A distributed architecture which realises a possible instance of the developedenvironment was presented. The architecture consists of a federated set of looselycoupled managers which interact to provide services to CSCW applications. Thecurrent architecture is still under development and a set of services for each of themanagers is currently being explored.

Cooperative system will be among the many users of future communication anddistributed systems services. It is important that these services are presented to CSCWsystems in a manner which allows them to be easily exploited. This paper has presentedan initial attempt at specifying what these services might be and how they would berealised within a particular architecture. It is likely that future communication anddistributed services will grow to incorporate many of the services presented in thispaper.

6. Acknowledgements

A great deal of the work presented here could not have taken place without input fromthe members of the Mocca group. We are grateful to these group members and thankthem for the work they have put into the project and the inspiration and comments theyhave provided for the work presented here. The Mocca group are funded by theEuropean commission under its COST-14 COTECH initiative.

13

7. References[ANSA 89] ANSA. 'ANSA: An Engineer's Introduction', Release TR.03.02,

Architecture Projects Management Limited. November 1989.

[Cook 87] Cook P., Ellis C., Graf M., et al ' Project NICK: MeetingsAugmentation and Analysis', ACM trans. on Office InformationSystems, Vol 5, No 2, April 1987,pp 132-147.

[Crowley 90] Crowley T., Milazzo P., Baker E., Forsdick H., Tomlinson R. 'MMConf: An infrastructure for building shared multimediaapplications', in proceedings of CSCW 90, Los Angeles, CA,October 7-10 1990, ACM press , ISBN 0-89791-402-3.

[Danielson 86] Danielson T., Panoke-Babatz U. et al ' The AMIGO project:Advanced Group Communication Model for Computer-basedCommunication Environment', in proceedings of CSCW86,Austin,Texas,December 1986.

[De Cindio 86] De Cindio F., De Michelis G.,et al ' CHAOS as a CoordinatingTechnology', in proceedings of CSCW 86, Austin, Texas, December1986.

[Ellis 91] Ellis, C.A., S.J. Gibbs, and G.L. Rein. ‘Groupware: Some issuesand experiences.’ Communications of the ACM Vol: 34 No.: 1,January, Pages: 38-58.

[Kreifelts 86] Kreifelts T. Woetzel ‘ Distribution and error handling in an officeprocedure system’ Proceedings IFIP WG 8.4 Working Conference onOffice Systems Methods and Tools, Pisa, Italy, 1986, p 197-208.

[Patterson 90] Patterson, J.F., Hill, R.D., Rohall, S.L., Meeks, W.S. 'Rendezvous:An architecture for synchronous multi-user applications', inproceedings of CSCW 90, Los Angeles, CA, October 7-10 1990,ACM press , ISBN 0-89791-402-3.

[Prinz 91] Prinz, W., Pennelli P., 'Relevance of the X.500 Directory to CSCWApplications', in J.M. Bowers and S.D. Benford (eds): Studies inComputer Supported Cooperative Work. Theory, Practice andDesign, North-Holland, Amsterdam, 1991.

[Rodden 91] Rodden T., Blair G., ‘ CSCW and Distributed Systems: The Problemof Control’ in proceedings of ECSCW’91,Amsterdam, 25-27thSeptember 1991, Kluwer.

[Sheperd 90] Sheperd A, Mayer N., Kuchinsky A., ‘ Strudel- An extensibleelectronic conversation toolkit’, in proceedings of CSCW 90, LosAngeles, CA, October 7-10 1990, ACM press , ISBN 0-89791-402-3.

[Stefik 87] Stefik M., Foster G., et al 'Beyond the chalkboard: computer supportfor collaboration and problem solving in Meetings', Comm ACM Vol30, No 1, January 1987.

[Wilbur 88] Wilbur S.B., Young R.E. 'The COSMOS Project : A Multi-Disciplinary Approach to Design of Computer Supported GroupWorking', in R. Speth(ed) EUTECO 88: Research into Networks andDistributed Applications, Vienna, Austria, April 20-22,1988.

[Winograd 87] Winograd T. 'A language/action perspective on the design ofcooperative work', Stanford University Department of ComputerScience Technical Report , STAN-CS-87-1158.