Environment Support for Cooperative Working Leandro Navarro, Manel Medina Universitat Politècnica de Catalunya Barcelona, Spain
[email protected] [email protected]
Tom Rodden Computing Department, Lancaster University, Lancaster LA1 4YR, U.K.
[email protected]
The role of the computer in supporting the work of individuals is now widely accepted with the widespread application of tools to support professional work. More recently, computer systems have becoming increasingly used to support the work of groups as well as individuals. This trend has resulted in the emergence of a Computer Supported Cooperative Work(CSCW) [Ellis 91] as a research area. Distribution and communication technology have a significant role to play in the development of computer systems to support group work. This paper examines the issues surrounding the support of CSCW systems and how this can be achieved by the development of a CSCW environment. This paper introduces an approach to the development of a CSCW environment and its implication for distributed systems. The components of a CSCW environment are introduced and a possible architecture for the realisation of the environment model is presented.
1. Introduction Cooperative work does not occur in isolation. Instead, the general picture is of many inter-related work activities taking place within a common environment of shared resources, people and information. Very often, the environment will be the representation of the organisation(s) within which the activities occur (e.g. the companies involved in the large engineering project or a University college offering a course). In other words, COOPERATIVE WORKING NEEDS TO BE CONSIDERED IN TERMS OF NUMEROUS RELATED ACTIVITIES INVOLVING THIS WORK OCCURRING WITHIN AN ORGANISATIONAL ENVIRONMENT.
As CSCW applications become more widely available, it will become increasingly necessary to focus on the relationship with their environment. Such an environment should be aimed at allowing a multiplicity of CSCW approaches and paradigms to coexist. CSCW application do not exist in isolation but become an integral part of the activities which take place within the organisation they are embedded. If one considers the nature of group working in a large scale over a long time period, it becomes apparent that any major activity typically involves the complex interaction of numerous subactivities. For example, the management of a large scale engineering project can be undertaken as a cooperative activity. The overall task may involve an on-going programme of subactivities such as team progress meetings, the joint production of reports, monitoring and interviews as well as more ad-hoc, informal communication between project members. 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 )
1
• They share common information. The information produced by one activity may be used in another. For example, a progress report of one activity 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 in between. There are also many differences between the activities. For example, some have well defined goals and fixed deadlines while others are on-going. They may also utilise different underlying communication technologies. The current generation of CSCW applications provide models and mechanisms aimed at supporting either a particular cooperative activity or class of activities. Each of these systems often postulate their own particular view of activities and how they should be structured. These systems differ both in the formal basis of how they model cooperation and how they represent the cooperation to users. Some exploit formal models based of either speech act theory or office procedures while others adopt a considerably less formal approach. Similarly, some systems use scripts to represent cooperation while others exploit either network diagrams or production rules to describe cooperation. The table below lists a number of significant CSCW systems and the different techniques used to model and represent cooperative activities. Research Project Coordinator [Winograd 87] Information Lens [Malone 87] Chaos [De Cindio 86] Domino [Kreifelts 86] Cosmos [Wilbur 88] Amigo [Danielson 86] Strudel [Sheperd 90]
Cooperation Model Formal , Speech Act Semi-Formal Formal, Speech Act Formal , Procedural Model Formal , Augmented Procedure System Formal , Augmented Procedure System Semi-Formal
Representation Network Production Rules Network Script Based Script Based Script Based 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 other applications and provide few mechanisms for working in conjunction with other applications (Figure 1a). Given the strong interdependences across these various worktasks this is a severe limitation of current CSCW systems. The role of a CSCW support environment is to provide interoperability between a variety of CSCW applications ensuring that CSCW applications can work in harmony rather than in isolation of each other (Figure 1b).
2
CSCW Application CSCW Application
?
CSCW ENVIRONMENT
? CSCW CSCW Application Application
?
CSCW Application
CSCW Application
CSCW Application
CSCW Application CSCW Application
CSCW Application
?
CSCW Application
CSCW Application
Figure 1a: Independant CSCW Applications
Figure 1b: CSCW applications in an Environment
A number of recent systems have considered the need for providing support services for CSCW applications. Most notably MMconf [Crowley 90] and Rendezvous [Patterson 90]. However this systems have concentrated on the development of infrastructures to support features of various real-time CSCW applications. In addition, researchers have demonstrated how CSCW applications could utilise different OSI standards to provide infrastructure support [Prinz 91]. The work presented here differs from previous work in that the environment wishes to provide facilities to allow an understanding of the cooperation involving different CSCW applications to be shared. In particular, what is considered within this paper is an architecture for a computer based environment which provides a range of supporting services for establishing and running different activities. These services may be realised as 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 information between 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 organisational procedures. • 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, for example, OSI facilities
3
It is our believe that the development of a cooperative support environment within an organisational context is an important issue for cooperative work technology. This paper considers the issues central to the development of this environment and postulates a possible architecture which allows a CSCW environment to be realised. A Cooperation Environment should provide some degree of transparency 1to facilitate people cooperating from different coordinates, distributed at different locations of a multidimensional 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 the complex interaction of numerous sub-activities. The current generation of CSCW applications are closed and provide little support for integration . A significant role of a Cooperative Environment is to provide inter-operability between a variety of cooperative applications ensuring that CSCW applications can work in harmony rather than in isolation of each other. To achieve this inter-operability between cooperative systems will require the development of "open" CSCW systems. These systems will be open to both integration with other CSCW systems and the augmentation of these systems by both users and developers. It is our belief that open Cooperative Systems will need to be based on an Environment which gives support for the idealization, realization and usage processes of cooperative applications. The role of this environment is to abstract the complexity of the 'Real Cooperative World' surrounding a certain application. At the same time, applications, as opaque objects within the environment, may look homogeneous in their use of the environment at any point of the modelling process. It is important that the development of Open cooperative systems and their associated environment should be based on present and future international standards. In this direction, the Environment presented here is considered in terms of the emerging ODP Reference 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 is that of transparency. Recent work on distributed systems has clarified the meaning of the term transparency [ANSA 89] . Distribution transparency is seen as a collective name for the masking out of various features of a distributed computation. Each of these features can be thought of as an additional dimension of transparency. A significant aim of a cooperative environment is to define a distributed architecture that provides several degrees of transparency, to hide some dimensions that are unnecessary for the cooperative activity and makes the system more complex. However, in certain circumstances , applications may need to be aware of what is going on. Given the flexibility of CSCW systems is important that the concept of selective transparency is applied within cooperative environments [Rodden 91] and that the degree of transparency can be selected and modified. A number of different transparencies are important to the development of a cooperative environment. The transparencies central to the development of an open cooperative environment are briefly listed in the table over:-
1
This is also called "selective transparency".
4
Transparency
Central Issue
Result of transparency
organization
The organizations to which objects are members The time dependence between cooperating users, i.e synchronous vs asynchronous cooperation Local or remote localization of objects The interest on a small subset of objects, those pertaining to a domain The application of different views per user. For example, WYSIWIS The coordination and complexity of cooperative activities
Objects do not have to deal with differences between organizations System design independent of form of interaction
time
location domain
view
activity
security
Security concerns
Objects unaware of the location of other objects Objects are unaware of the existence of other unrelated objects Users are unaware of the different views of other users Objects are unaware of the mechanism for running activities involving the coordination of several objects Objects are unaware of the application of the security policy
Table 2 Different forms of transparency for CSCW The definition and maintenance of these transparencies is a central feature of a cooperative environment. The set of transforms outlined above represent only some of the salient features of cooperative working where the use of selective transparency within 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 'realworld' metaphor. Essentially, the metaphor shows an organization as a set of rooms connected by doors, through which people move and within which they work (figure 2). People are always able to communicate in an unstructured way. This unstructured interaction may be augmented by additional communication tools and more specialised/structured communication facilities.
Figure 2 A cooperative rooms setting Inside a room within our example world, people are aware of other people and have open channels through which they can communicate. Three important points emerge from this arrangement. • Informal communication is always possible via these channels.
5
• All work, individual as well as explicitly collaborative, takes place in some space and 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 the environment, allowing a wide diversity of cooperative situations to be consider. In our approach to developing the environment models are constructed by abstraction of the properties common to all possible distributed systems3 and the need to be able to express the requirements relevant to distributed processing of all possible enterprises4. This process is represented in figure 3.
ents rem i u Req
All Possible Enterprises Req uire me nts
Abs Models tra Des ction crip tion Choice All possible Cooperative Systems
Open Cooperation Reference Model (OC-RM)
Pre scri ptio n
Open Cooperation Reference Model (OC-RM)
Choice Specific Environment Components
All possible Open Cooperative Systems (OCS)
Pre scri ptio n All possible Open Cooperative Systems (OCS)
Pre scri ptio n Environment conforming Open Coop. Systems
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 have briefly outlined in the previous section. These requirements have resulted from a range of ongoing activities within the Mocca group. These requirements help to describe each model, and to discover the functionality of the Environment. This is an ongoing process with the developing Environment prescribing how Cooperative Applications should 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. 2 3
4
5
6 7
Main interest in projects such as AMIGO Advanced, Chaos, Domino and Cosmos. Transparency, separation, location, cooperation, concurrence, heterogeneous, fault tolerance, isolation, incremental change, autonomy, time, ordering, performance. These are descriptive models: all examples of enterprises can be represented by that model. The model merely describes what the salient properties of a model should be. Common Components (and functions) for the Environment can be chosen by consensus. Some activities could need specific components (e.g. a document store for Joint Editing). OCS: Set of CSCW applications cooperating in an organizational setting. Reference point: An interaction point declared in a standard as a point at which behaviour may be observed for the purposes of conformance testing. There are four classes that allow testing: at a programmatic interface (C binding of SQL), at a human computer interface (graphics standard), at a point of interconnection (OSI standards), of an external physical storage medium (information interchange standards).
6
3. The General Mocca Architecture The general Mocca architecture provides a set of loosely connected managers which provide appropriate portions of cooperative support. These managers are intended to abstract over the services provided by existing OSI and ODP platforms is a simple and versatile manner. The set of managers within Mocca is intended to be extensible so that a Mocca platform which realised this architecture could readily evolve as the nature of the cooperative work being supported altered. Two of the managers currently identified by the Mocca environment are aimed at supporting the manipulation and storage or information. Most cooperation involves the sharing of information which often provides a focal point for the cooperation taking place. Subsequently a central repository, an information store, for shared information as in environment places a significant role is a cooperative environment. This is augmented within a cooperative environment by the provision of an organisational database which allows organisational information to be shared. In addition to the static organisational knowledge held within the organisation knowledge base active support within the environment is provided by three active components, the domain manager, the activity manager and the security manager. The general architecture is presented in figure 4. Application living in the Environment
User access
User access
User access
Loosely Coupled managers. A set of managers defines a specific instance of a cooperative envitonment.
Organizational Database
Domain Manager
Information Store
Activity Manager
Security Manager
XX Managers
OSI / ODP Computational Platform
Figure 4 The Mocca cooperative architecture This architecture provides a set of optional interfaces for an application within the environment. This allows an application to maintain as many different ports as managers wants to interact with. The more ports are used, the more environment aware is the application. The extreme situation would be an application without any port to any manager: this application will have to contact to other objects. That service is provided by the domain manager, and supervised by the security manager. The environment should allow services to be easily added and removed from the environment as future additional common services are identified.Several initial services central to a cooperative environment have been identified: an organisational database, a domain 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 environment have a connection (is a well known object/service). It has key importance during the
7
configuration phase of distributed activities. It receives requests from objects requesting services (connection to other objects), it consults the Organizational Database and establishes connections between objects (working phase). It can also receives requests from Domain Managers pertaining to different organizations to set-up interorganizational domains or activities. One of the services offered by the Domain Manager is the management of domains which are abstraction over sets of objects within the environment. Objects can be grouped into domains to simplify the set of alternative objects available. This can also be used to separate/isolate objects with the same aspect (operations) but different kind of services. Domains will be structured in an acyclic graph (no loops, but a node can have more than one father). To support a concrete activity it should be decomposed in terms of objects available in the environment and the application specific objects. A domain could be defined for this activity, and objects put in that domain. In the configuration phase, a domain (or a part of the domain tree) is consulted to look for services (objects) registered or visible. Requests are made to the Domain Manager and, after consulting the Organizational Database, 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 by themselves, without any intervention from the Domain Manager. It is expected that the domain manager will make us of underlying directory services such as those offered by X500. 3.2 The Activity Manager A central objective of the MOCCA work is to allow some degree of integration across different models of cooperative work and applications based upon those different models. This suggests that: • Applications based on particular models should be easily integrated into the Environment (to use/interact with the Environment and other entities). This requires something to translate from particular mechanisms to mechanisms supported by the Environment. • Activities and/or applications can be integrated (composed objects) to form new activities. This means that we also need to provide some mechanism which will allow different entities to inform each other when certain conditions have occured. 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 to be registered outwith the application in the MOCCA Environment. Other applications interested in that activity can also register their interest in the status of that activity with the Activity Manager. For example, an application may wish to publicise that it is involved in the development of an production plan for a bridge. To do so an application would construct an activity entry in the Activity Manager from a set of central services in the Environment. We have assumed that: activities are modelled as objects, and that the Activity Manager manages dynamic information: references to running activities, while the Organizational Database manages more static information: it contains Activity Templates and organizational restrictions to instances of those activities.
8
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 in the Organizational Database. This activity template contains the information that entities in the Environment should know about the activity. Registration in the Organizational Database 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 other organizational restriction to activity instances of that activity template). More dynamic activities will not have an activity template object registered in the Organisational Database. An entry representing the activity instance will be created dynamically 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 of the major responsibilities of the Activity Manager. It acts as an event router. Activity instances are registered in the AM and entities can browse and get information about the events that an activity can produce. An object can register interest on a subset of events generated by activities. Events are items composed of one or several attributes that convey specific information about 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 activity can send an event to a set of objects or domains (subject to organizational and security restrictions). Event processing and filtering can be seen as convenient. This means that entities can provide rules or scripts to process/filter events. These are event handler objects. The AM routes events to them, events are processed there, and new events may be generated. For example, the event "ProjectFinished" is generated by a particular event handler object when all employees have finished or the time is gone, and the project manager has filled the administrative form. Using the concept of specialization, the AM can 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 the environment. It should be able to store information elements, structures, rules and complex objects. Requirements for concurrent access and quality (e.g. accuracy, reliability, consistency, availability, lifetime, etc.) will be diverse ranging from critical long term data, to short term state information data. One key function of this store is to provide inter-operability among different objects by sharing a common service access point and information representation. The service will be used not only by Managers, but also by application related objects. The diversity of requirements may lead to the decomposition of a single Information Store (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 the Information Store a certain degree of transparency to that matter. 3.4 The Organisational Database The organisational database contains information about the organisation in which the environment is set. The organisational database represents an organisation in terms of
9
the resources used within it, the employees working for it, the roles they play and the organisational 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's boss" and informal relationships of the form "tom manages system configuration" can both be represented. The organisational database will allow applications to exploit these relationships to encode the assignment of responsibility within an organisation. The organisational database allows information regarding organisation members expertise and interests to be stored and queried by systems. This information will often map onto underlying structures and services such as those provided by X500. Finally, the organisational database allows organisational roles and policy to be stored and accessed by a number of different cooperative systems. 3.5 Security Manager One important concern in a inter-organizational-distributed-cooperative environment is security. The security manager object groups all matters related to security. Security is concerned with ensuring that the resources of the system are available to those 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 confidentiality of resources. Organizations are responsible for describing a security policy which allows measures to be taken against possible threats to the security of the distributed system (e.g. unauthorized disclosure, contamination, misuse of resources, repudiation, denial of service). 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 be realized. 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 of relationships with elements outside its domain.
4. A Simple Example Let us consider the case of a seminar or lecture room with a white laminated board which can be written by anyone in the room. Within the room there will be a number of cooperating users. This scenario has been addressed by a number of CSCW systems including CoLab [Stefik 87] and Project NICK [Cook 87] and provides a useful concept demonstrator for the Mocca architecture. In our example whiteboard each cooperating user has a number of mechanisms for interacting with the wall. Inspection mechanisms View which allows them to see on the wall. Views allow users to focus on particular parts of the wall
10
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
Any object can be attached to the wall
This is the drawing surface for user A.
Sample document
Here is where user B writes
File
Edit
Figure 6 A shared whiteboard The whiteboard can contain more than simple drawings or text (figure 6). It can be modelled as a surface composed of elements and each user with has a pen has the right to draw or to put things in the wall. To avoid the problem of concurrent access, each user owns a transparent overlay layer which is coincident with is his view. This means that no user can "compete" with each other: they work at different layers. Concurrence and ownership are guarantied. These views are registered (they have a name) on a whiteboard object. This lets users to choose a common sub-area of the wall and work there together. Sub-areas can overlap and sub-areas can be further subdivided. Organizational Database
White wall
Configuration phase
Organizational Database
Duster
Pointer Domain Manager
Pen Pen
Working phase
White wall
Duster
Pointer Domain Manager
Pen Pen
User Interface
User Interface
User Interface
User Interface
User Interface
User Interface
User
User
User
User
User
User
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 the configuration phase resources are assigned and organizational restrictions implemented by the domain manager. In addition, some wall configuration options can be negotiated by the domain manager (for example, overlapping of transparencies, maximum number of simultaneous users, etc..) After the configuration phase, user-access objects have a direct connection to the objects that have been assigned to them. If some object wants to change his configuration in the "Working phase", the Domain Manager will be contacted. That means that the Domain Manager object is a well-known service: all objects have always a connection to it. The Whiteboard object is concerned with the management of the group tasks associated with interaction with the shared wall surface. If it was felt that a whiteboard was a
11
generically useful service within the environment it could be incorporated into the set of managers within the environment. Pointer, duster and pen objects realise the interaction mechanisms with white wall objects. They have been modelled as objects to reflect that the number can be limited and that they are assigned in the configuration phase by the Domain Manager in cooperation with the Organizational Database. Another alternative would be not to model pointer, duster and pen as objects. Then we will have rights (to point, erase and paint) which will be negotiated during the configuration 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 or pen (or any combination of them). We would say that the user access object is compatible 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 it may 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 become passive participants, to be notified when the activity finishes (to try to grab the resources being used), etc. If the activity is considered relevant and reusable in the future, someone may apply to the organisational database to register an activity template based in the current activity instance. This activity template will contain some information that will simplify future activity instantiations of that activity. In this example, the Security Manager has not been used explicitly, but it has been monitoring and enforcing the security policy of the organisation where this activity took place. This is an example of transparency: the security policy has been followed without any concern from the application. The application has delegated that functionality to the environment (the Security Manager provides that functionality).
5. Summary and Conclusions This paper has presented an approach to developing an environment for cooperating working which provides an abstraction over existing OSI and ODP services and platforms. A modelling approach based on a real world metaphor is used as part of the environment development . The environment is designed to implement a number of distinct transparency which extend the existing concept of transparency within distributed systems. A distributed architecture which realises a possible instance of the developed environment was presented. The architecture consists of a federated set of loosely coupled managers which interact to provide services to CSCW applications. The current architecture is still under development and a set of services for each of the managers is currently being explored. Cooperative system will be among the many users of future communication and distributed systems services. It is important that these services are presented to CSCW systems in a manner which allows them to be easily exploited. This paper has presented an initial attempt at specifying what these services might be and how they would be realised within a particular architecture. It is likely that future communication and distributed services will grow to incorporate many of the services presented in this paper.
6. Acknowledgements A great deal of the work presented here could not have taken place without input from the members of the Mocca group. We are grateful to these group members and thank them for the work they have put into the project and the inspiration and comments they have provided for the work presented here. The Mocca group are funded by the European commission under its COST-14 COTECH initiative. 12
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: Meetings Augmentation and Analysis', ACM trans. on Office Information Systems, 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 multimedia applications', 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-based Communication Environment', in proceedings of CSCW 86,Austin,Texas,December 1986. [De Cindio 86] De Cindio F., De Michelis G.,et al ' CHAOS as a Coordinating Technology', in proceedings of CSCW 86, Austin, Texas, December 1986. [Ellis 91] Ellis, C.A., S.J. Gibbs, and G.L. Rein. ‘Groupware: Some issues and experiences.’ Communications of the ACM Vol: 34 No.: 1, January, Pages: 38-58. [Kreifelts 86] Kreifelts T. Woetzel ‘ Distribution and error handling in an office procedure system’ Proceedings IFIP WG 8.4 Working Conference on Office 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', in proceedings 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 CSCW Applications', in J.M. Bowers and S.D. Benford (eds): Studies in Computer Supported Cooperative Work. Theory, Practice and Design, North-Holland, Amsterdam, 1991. [Rodden 91] Rodden T., Blair G., ‘ CSCW and Distributed Systems: The Problem of Control’ in proceedings of ECSCW’91,Amsterdam, 25-27th September 1991, Kluwer. [Sheperd 90] Sheperd A, Mayer N., Kuchinsky A., ‘ Strudel- An extensible electronic conversation toolkit’, in proceedings of CSCW 90, Los Angeles, CA, October 7-10 1990, ACM press , ISBN 0-89791-4023. [Stefik 87] Stefik M., Foster G., et al 'Beyond the chalkboard: computer support for collaboration and problem solving in Meetings', Comm ACM Vol 30, No 1, January 1987. [Wilbur 88] Wilbur S.B., Young R.E. 'The COSMOS Project : A MultiDisciplinary Approach to Design of Computer Supported Group Working', in R. Speth(ed) EUTECO 88: Research into Networks and Distributed Applications, Vienna, Austria, April 20-22,1988. [Winograd 87] Winograd T. 'A language/action perspective on the design of cooperative work', Stanford University Department of Computer Science Technical Report , STAN-CS-87-1158.
13
