Two complementary tools for the cooperation in a ministerial environment

Abstract: This paper describes the realisation of and experiences with two complementary tools for the support of cooperative processes: electronic circulation folders and shared workspaces. Circulation folders support structured work processes, shared workspaces provide a working environment for less structured processes. Both approaches are complementary and their combined usage provides new and very flexible ways of telecooperation and cooperative knowledge management. The components are integrated in the POLITeam system which is developed for the support of cooperative processes between the separated ministries in Bonn and Berlin.

1 Introduction

The CSCW research area has yielded numerous groupware applications for cooperation support. Most groupware applications focus on the support of special aspects of cooperative work, such as workflow coordination, document sharing, or video-conferencing. However, cooperative processes are not limited to a specific pattern. Thus, the integration of different groupware functionalities is needed to span and support a range of different cooperation patterns.

This paper presents selected components of the POLITeam¹ system: electronic circulation folders to support workflows and shared workspaces to support document sharing. Electronic circulation folders offer a functionality similar to their concrete counterparts. Users can add documents to a folder, specify the path the circulation folder should take on its way through an organisation and forward it along this way. Circulation folders provide a good facility to support structured cooperation

processes, but offer enough flexibility for exceptions and the support of ad-hoc workflows. Shared workspaces support less structured cooperation processes. They provide their users with a shared working environment, a place to store common working documents and tools. The seamless integration of both tools in a cooperation support system provides users with easy means to switch between both tools. Their combined application allows for new ways to structure and organize cooperative processes and knowledge management.

The design of the POLITeam system is based on an evolutionary process, in close cooperation with selected pilot users working in a German federal ministry, a German state ministry, and for a car manufacturer. Starting with an existing groupware system the pilot users are supported by this system in their daily work. Their experiences are gathered, new requirements derived, and considered for the next design cycle. We will reflect this process in the course of this paper.

First, this paper presents an application scenario from the federal ministry. This provides an understanding for the environment in which the POLITeam system is used. Furthermore the scenario reveals requirements which have guided our developments. Then we introduce the POLITeam components electronic circulation folders and shared workspaces in more detail. We present a design concept for CSCW systems which supports the design of flexible CSCW systems allowing to combine different basic CSCW functionality and to provide the end-users with the possibility to configure this functionality. Finally we show how both tools allow for an easy switching between different work patterns and how their complementary use supports new work practices.

2 Application Scenario

This section considers the scenario of preparing a speech for the minister without computer based cooperation support. It shall provide an understanding for our application environment and we will use it later to derive design requirements for POLITeam.

The request for the speech is issued by the minister's office. Together with the request additional background information that is useful for the preparation of the speech is collected in a circulation folder. The minister's office addresses this folder to the head of the department responsible for the speech topic. It is also common practice that the minister's office already prescribes the sequence of addressees down to the unit level of the ministry.

Figure 1 illustrates that the processing of this request involves several hierarchical levels. The managers at the department and subdepartment level are each supported by a secretary, who performs additional tasks on incoming or outgoing documents. For example, this includes the sorting of incoming folders according to their priority that is indicated by three different colours of the circulation folder. The manager at each level acknowledges the receipt of the folder, i.e. the speech request, and

additionally provides comments or advices for further processing. As a speciality the comments and the signature are performed using a colour pen. The colour corresponds to the role and position of the manager in the hierarchy.

Even though the subsequent addresses of the circulation folder are already predefined by the minister's office, the manager may reroute the folder or inform subsequent recipients about the process as the situation demands. Before the circulation folder is received by the units its contents is registered by the registry.

At the unit level of the ministry the speech is prepared in a cooperative process between different people of the same unit or different units. This process is not determined by any particular order. The person who initiates the cooperative process decides who should or must be involved in the production of a document, or whether contributions to the document are collected in a sequential order or in parallel. Members of the unit level are supported by a writing office that types the hand- written or audio-taped drafts they produce. The cooperation process is characterised by a frequent exchange of documents between the members and the writing office if the modification of a draft requires the production of new versions.

Figure 1: The flow of a circulation folder in a ministry.

After the creation of a typed draft version, it is sequentially processed by the managers of the unit, sub-department, and department. Each manager reviews the speech and additionally annotates the document with own comments to the proposal. Before the proposal is forwarded to the next higher level the managers approve the cover note that is attached to the proposal with their signature. Again coloured pens are used for that purpose. If necessary the manager may return the proposal to the preceding recipients, but more often questions or comments to the proposal are discussed by phone.

After the proposal for the speech has been finally commented and approved by the minister or his assistants it contains a lot of hand-written comments. This document is then retyped by the writing office. Often its members use the previously stored draft version of the text and modify this according to the hand-written annotations on the paper document.

This scenario briefly discussed the major steps of the preparation of a speech for a minister. Although this describes just a special process out of large number of different processes that are handled by a ministry, it is typical in the sense that most processes are treated in the same way: a top-down processing of documents through the organisational hierarchy, a cooperative production of a document at the unit level, and then a bottom-up approval process through the organisational hierarchy. The following section identifies some essential requirements for a computer based support of such processes.

3 Requirements

The scenario might suggest that ministerial procedures can be suitably supported by workflow systems. Workflow systems coordinate the flow of work based on a prescribed model of the office procedure [Kreifelts, Licht, et al., 1984]. Although ministerial workflows appear to be strictly regulated, they cannot be predefined completely. Depending on the actual situation, the employees involved in a procedure may return the documents to the last station, change recipients, add an additional recipient, add additional documents, or temporarily remove documents to discuss them with colleagues. These are just a few examples of possible actions on a workflow document, but they demonstrate that the workflow cannot be completely prescribed from the very beginning. The actual processing of a circulation folder and the contained documents thus depends on the current situation. Therefore a workflow system that requires the complete prescription of a workflow and that does not allow the modification or circumvention of a given procedure would not be applicable for our purposes. As a primary requirement we can identify that a flexible coordination medium is required for the electronic support of ministerial workflows. The flexibility should encompass easy means for the modification of the workflow route and the ability to transport arbitrary documents that can be easily added and removed from the circulation folder.

Further requirements for the workflow support can be identified by a more detailed look at the document processing at the various steps. It happens that managers receive up to 30 or 40 folders, three times a day. In the case of documents that are further processed by the units this pile of folders is processed within 15-20 minutes. This requires that an electronic solution must provide means for a rapid browsing and annotation of documents. Documents that are produced by the units must be approved by the managers. This requires secure electronic signatures and the possibility to reconstruct the document history to identify the changes and annotations made by the managers at the different levels. To support the discussion of a document between a manager and a unit member it is feasible to include a video-conferencing and

application sharing functionality. However, we do not assume that all processes will be handled electronically. In many cases a procedure will consist of electronic and paper documents. Thus, a solution for the combination of non-electronic media with the electronic information processing is necessary.

With regard to the cooperative production of documents by several members of the unit supported by the writing office, we can offer electronic support by providing shared workspaces. The scenario reveals several requirements that are to be considered here. The process involves different persons of the same unit or different units. Neither the persons who should contribute to the process nor the individual steps of the process can be prescribed in advance. The person who initiates the process decides on the participation. As a consequence a workspace should offer the possibility to declare a person to be "supervisor" of the workspace. This person is allowed to decide on the membership of the workspace and - since the membership is subject to changes - to invite new members or to exclude persons during the existence of the workspace. Nevertheless each member should have the possibility to finish participation and to leave the workspace. Furthermore the supervisor should be allowed to hand over privileges to another person.

The order of contributions to the cooperative process cannot be predetermined but follows from the activities of the cooperation partners. Therefore it is very important that each of them has access to the latest versions of the documents. The workspace provides its members with an environment where they can store all documents belonging to the cooperative process and access the documents worked on by their cooperation partners. By these means each person has the possibility to get an overview about ongoing activities and the progress of the cooperation.

The next sections present our approaches to satisfy basic requirements to the cooperation tools and some experiences with their use by the application partners.

4 POLITeam Solutions and Experiences

It is the primary goal of POLITeam to base the system design on requirements that are derived from user experiences with the actual use of a groupware system in a ministerial working environment. For this purpose it is necessary that a groupware system is available and used by the application partners that provides a basic support for the users cooperation needs. We have chosen LinkWorks, an object-oriented, client-server groupware product by Digital [LinkWorks, 1995] as the start-system for the requirement analysis and as platform for our developments.

This process of implementing POLITeam at the pilot partners site is characterised by the installation of a first basic version that provides general support for the individual and cooperative work. Based on the user participation the system is then iteratively enhanced to become more appropriate for the daily work and more specific for ministerial environments. A detailed description of the methods that we apply can be found in [Pankoke-Babatz, Mark, et al., 1997].

The following section presents solutions for a flexible support of ministerial processes as described previously with the support of electronic circulation folders and shared workspaces.

4.1 Circulation Folders

POLITeam provides electronic circulation folders, similar to [Karbe, Ramsperger, et al., 1990] as a flexible workflow coordination medium. It corresponds to the paper- circulation folder that is described in the previous application scenario as the document transport medium. With that cooperation tool we aim to support the cooperative processes in the ministry by the provision of a user tailorable cooperation medium and not by the provision of predefined cooperation mechanism [Bentley and Dourish, 1995 [Grudin, 1994]. More sophisticated workflow coordination mechanisms [Schael and Zeller, 1993] [Glance, Pagini, et al., 1996] are not applicable in this organisational environment since these would require an over-specification of the cooperation process.

The next section describes the basic functionality of the circulation folder. Afterwards we describe various extensions to this functionality to satisfy the specific needs identified previously.

4.1.1 Basic functionality

The electronic circulation folder is capable to transport arbitrary electronic documents, e.g. spreadsheets, presentations, audio, or video objects. It is fully integrated into the POLITeam electronic desktop. Users add or remove documents by simple drag and drop operations between the folder, the desktop, other folders, and containers. Access to the documents is controlled by access rights that determine the operations that users can perform on the folder (e.g. the removal or inclusion of new documents) and its contents (e.g. reading or modification of documents). The route of the circulation folder is described with a configurable circulation slip. It sequentially lists all recipients of the circulation folder. If a specific workflow requires parallel processing of a document this can be expressed, too. The contents of the circulation slip can be modified easily by the recipients of the circulation folder. This allows users to react flexibly on situations that require a change to the described route of the circulation folder.

Figure 2: An opened circulation folder and its circulation slip.

Figure 2 illustrates the symbolic representation of a folder on the desktop, its contents, and the attached circulation slip.

4.1.2 Extensions

The electronic circulation folder supports the flexible routing of arbitrary electronic documents. To satisfy the specific requirements of a ministerial environment a number of additional functionalities needed to be realised. These include electronic signatures, information about status and locality of a circulation folder, the integration with paper documents, an interface for fast browsing through a pile of folders and the integration of a video conferencing system.

4.1.2.1 Electronic Signatures The support of workflows that span different hierarchies requires a solution for secure signatures to electronic documents and the ability to reconstruct the complete history of modifications to a document made by the users involved in the workflow. In particular the latter is required to clarify responsibilities for political decisions. In POLITeam the secure authentication of signatures is realised by the integration of SecuDE, the Security Development Environment [Schneider, 1993] into the base system LinkWorks. With the SecuDE integration it becomes possible to sign electronic documents with digital signatures according to the RSA technique [Rivest,Shamir, et al., 1978].

The user interface design of the electronic signature list adopts the structure of the cover note that is attached to each workflow. It supports the repeated commenting and signing of a text according to a signature list. This list contains the persons who are expected to sign the document row by row. By selecting a row of the signature list that contains a signature, the version of the document is displayed that has been signed by the appropriate person. The repeatedly signed document is stored in

different versions to ensure that the version a user has signed can be easily retrieved for control purposes. Thus a user who receives the document can ascertain the history of the document before the signature is performed. After a user has supplied his digital signature, his name, date, time and a comment are listed. The name of the signing person is read from a SmartCard that is used for the digital signature. This allows substitutes to sign a document and it indicates that a circulation folder has been processed via another route than the one that was specified when the signing process was initiated. The signature list is integrated with the electronic circulation folder such that it is ensured that all members of the signature list are automatically included into the circulation slip. Thus the members of the signature list determine the minimal contents of the circulation slip. It can be easily extended to include further or alternative recipients if this is demanded by the actual situation. A more detailed description of this solution can be found in [Prinz and Kolvenbach, 1996].

4.1.2.2 Status and Locality The capability of a workflow system to provide up to date information about the current state and location of a workflow is often considered as a major advantage compared to a paper based workflow processing. Our pilot users consider this functionality as very useful because they often perform time consuming searches for the current location of a folder. However, the detail of information that is provided by the standard LinkWorks workflow status window can be easily (mis-)used as a control instrument, because it provides a listing of the preceding and succeeding recipients of a workflow together with the dates at which users have received and forwarded the folder.

Since this level of detail was not acceptable and would lead to problems with the members of the works council when the system is used by the ministry in a larger scale, we needed to develop an alternative status display for POLITeam. This alternative should satisfy the users requirement for information about the current location of a circulation folder, but it should not display further details. Whenever a user moves a circulation folder into the mail outbox, a so called "shadow object" of that folder is created in the mail outbox. This shadow object wraps a circulation folder object by holding a reference to the forwarded circulation folder. Via this reference the shadow object can retrieve the current status of the circulation slip from the original electronic circulation folder. Thus whenever a user accesses the shadow object the status of the circulation slip is retrieved through this reference, but not the complete status is provided to the requesting user. Just a message of the form "This electronic circulation folder has been forwarded to Mr. Smith" is displayed. No further details are provided which can be misused as a control instrument.

4.1.2.3 Integration with Paper Documents While POLITeam aims at supporting users working with electronic documents, it still has to provide support for documents printed on paper. As an example, it is necessary to deal with incoming non-electronic documents. We propose a different approach to

integrate paper documents with the electronic system than the obvious scanning. Documents, for which it is not feasible to be scanned (e.g. books, large plans), are still distributed in a paper circulation folder as before. The only difference is that a bar- code label containing a reference number is attached to every circulation folder. Every time a user receives a circulation folder, he can easily find the corresponding electronic version by simply using a bar-code scanner in combination with a search tool integrated into the POLITeam environment. A circulation folder therefore consists of a non-electronic and an electronic part linked together by the bar-code. The two parts contain different documents - the first contains just the documents that are not available electronically, the second all others.

Ideally, the usage of electronic documents will increase over time when more users move towards using POLITeam for their daily work. We also expect that the preference of paper documents over electronic documents will change as soon as more departments are geographically separated.

4.1.2.4 Fast Browsing and Annotation of Process Documents

A department manager receives a pile of 30-60 incoming documents three times each day which are processed within 15-20 minutes. This indicates that an electronic support must provide means for a rapid browsing through electronic documents. Although the incoming documents will be of different types, e.g. scanned letters, fax, or email, the flow of work should not be disrupted by the need to start different applications for each document type.

Figure 3 presents an HTML-based interface for the presentation of and interaction with electronic circulation folders [Gräther, Prinz, et al., 1997].

Figure 3: The HTML interface for electronic circulation folders.

This interface allows the browsing of incoming documents of different formats (right part), the provision of comments and advices for the further processing of the document (left part) and offers an overview of meta-information of the document, and comments provided by predecessors of the document (middle part). We have chosen an HTML based interface that is enhanced by various Java applets since this provides flexible ways for the integration of viewers for different document types. Furthermore it allowed a design that is close to the appearance of the paper based process documents.

4.1.2.5 Integration of a Video Conferencing System

The main goal of POLITeam is the support of asynchronous cooperation. However, the application scenario identifies a need for the provision of tools that allow synchronous discussion of documents. In particular users at the management level that is still located in Bonn demanded a support function that allows the discussion of documents with members of units in Berlin. This support function has been realised by integrating a commercially available video conference and application sharing system that is based on ISDN or LAN connections into the POLITeam system. This provides a basic means of communication, e.g. to clarify questions arising during the processing of documents contained in an electronic circulation folder.

A more sophisticated integration which includes a customised access to the video system from various components of the POLITeam system is currently under development. This will allow users to record video sequences and to include these as video-objects in the electronic circulation folders. Effectively, this provides a simple form of video mail.

In this section we presented the design of an electronic circulation folder that integrates various extensions as a tool to support ministerial workflows. The following section describes the functionality and experiences with shared workspaces, a complementary cooperation tool.

4.2 Shared Workspaces

Whereas electronic circulation folders are mainly used to support the structured cooperation between the different levels of the hierarchy, shared workspaces [Agostini, Michelis, et al., 1996] support the cooperation among members of a unit or different units and the writing office. The POLITeam workspace provides its members with a virtual space for cooperation and communication. We differentiate between a person responsible for the workspace and "ordinary" members. For initialisation the user creating the workspace is responsible for it, but may delegate this task to another member of the workspace. Only the responsible person is allowed to invite new members to the workspace or to exclude an existing member by withdrawing the share. The decision to leave a workspace is left to each member.

Since the coordination of the activities within a workspace is not prescribed, it is important that other means of coordination support are integrated into the workspace. The POLITeam notification and information service provides its members with shared feedback about ongoing and past activities of their cooperation partners as far as cooperation issues are concerned [Sohlenkamp, Fuchs, et al., 1997]. This information allows the members to react on the activities of each other. An integrated video conference tool facilitates further coordination of asynchronous activities and even allows the transition to synchronous cooperation. The integration of task lists allows to impose more structure on the cooperative process by introducing subtasks and assigning responsible persons to these tasks. The following sections give an overview on the different design cycles for the shared workspace component we ran through in the POLITeam project.

As described earlier the development of the POLITeam system is based on the groupware product LinkWorks. In order to share a document with someone else, the user creates a share (which is a further access point, a handle to the object) to the document and sends this via e-mail to the user to be invited. Using the original LinkWorks solution, the user gets no information about who else has got a share to the object. Members that have once been invited cannot be excluded from the cooperation process afterwards. They even have the possibility to invite further members. Since this procedure is very difficult to explain to users that are not familiar with the underlying mechanism, we decided to hide it and provide our users with a different interface to the sharing facility. Different design rationales were important to us: the sharing functionality should

• be easy to understand and easy to use,
• allow the transition from single user objects to shared objects therefore no explicit shared workspace objects were introduced,
• focus on the sharing of container objects which contain further objects that are accessible to different cooperation partners and
• allow to limit the shared usage to a certain period of time.

The shared workspace component was designed and developed according to these requirements. The user of the POLITeam system can select an arbitrary container object on his desk and specify the users that are to be invited. If the access right to the container object does not allow a cooperative usage, the user is notified by the system and gets the chance to assign a suitable access right. The invited persons are notified about the invitation and find a share to the object in their mail inbox. They can move the icon representing the object to their preferred location on their personal desk. A special dialogue (shown in figure 4) tailored to the needs of our users informs them about who else is using the workspace.

Figure 4: A typical POLITeam desk showing a shared workspace and information about this workspace.

Different design alternatives were discussed within the group of designers: What is the best place to hand over a shared object to a new member? Two locations were discussed: the personal desk or the mail inbox. Placing a new object share on the desk of the user did not seem to be appropriate because of two reasons. First it results in modifying his personal desk and second it might be difficult for the user to detect the workspace on the desk. We decided in favour of the mail inbox being an entry point for incoming documents and equipped with a notification facility that announces changes to the user.

What is the best place to place a shared object? Here again the same problem occurs: when a user moves a shared object into a private container on his desk. The exclusion of the workspace member by the responsible person is no longer possible, since this would result in a modification of the private container. We decided not to restrict the users in their interaction with the system, but recommended not to store shared objects in private ones. The rest is left to the social protocol.

4.2.1 Extensions to Shared Workspaces

At the beginning of the POLITeam project we interviewed our application partners. These interviews helped us to get into closer contact with them and to gain some insight in their daily work. The answers to our questions should help to configure the first version of the system. Being asked if they could imagine to use electronic circulation folders or shared folders, the users stated their interest in the first cooperation media but could not think of the benefit of the latter approach.

The first version of POLITeam installed at the sites of our users offered electronic circulation folders as well as some predefined shared folders. The shared folders were

used to exchange documents between the unit and the writing office. The first experiences with these shared folders revealed two things. First, the users made use of these folders and discovered the advantages despite their disapproval of the shared workspace approach stated in the first interviews. This shows how difficult it is to articulate needs or requirements without having the possibility to experiment with a system [Kyng, 1994]. Second, the interaction of the users with the shared workspaces showed that they were not really aware of the shared usage. Some users moved documents out of the shared folder in order to edit them on their personal desk, not realising that their cooperation partners had no longer access to these documents.

The next version of the workspace component provided the users with an easy facility to create new workspaces. Additionally the members of the workspace had the possibility to get more information about the state of the workspace. After the installation of this version and some months of usage, we discussed the component and their experiences in a workshop. A vivid discussion revealed that our application partners required some conventions that frame their usage of shared workspaces [Mark and Prinz, 1997], as the following examples show.

Editing documents within a workspace. The application partners committed themselves to edit exclusively within the workspace in order to overcome the problems mentioned above.

Deletion of documents. Since the deletion of a document affects all members of the workspace, the application partners decided in favour of the following policy: Only the owner of a document is allowed to delete a document. One has to inform the other members of the workspace about this intention by mail and is only allowed to continue if no objection is raised within a certain amount of time.

Structuring the contents of a workspace. Since different persons have different preferences concerning the structure of a container, it is difficult to specify a common structure for shared workspaces. Whereas members of the units want to structure the workspace according to the different work processes, the writing office is mainly interested to gain an overview of the different types of texts at first sight. Furthermore there are different preferences according to the hierarchical structure of a workspace: whereas some members of the unit prefer to store all documents on the top level of the workspace, others like to make use of deep hierarchical structures.

These examples show that the introduction of a groupware system not only requires training of persons on the functionality of the system, but additionally to analyse work processes, make cooperative processes visible to the users and show how these processes can be supported electronically.

Our system should not only consider and realise the conventions mentioned above but offer a range of conventions. Different policies preventing the users from misusing the system are possible. Activities (as moving a document out of a shared workspace) can be forbidden, accompanied by a dialogue box making the user aware of the consequences, or handled in a different way (e.g. creating a copy of the document within the workspace). These examples show that it must be possible to configure the

behaviour of shared workspaces to reflect the usage patterns and conventions of a group. The next section introduces a design concept that allows to configure shared containers and to bind a specific set of conventions to them.

4.2.2 Design Concept

In order to react on upcoming new requirements the underlying system has to allow stepwise refinement of functionality and offer possibilities for configuration. A comparison of the development cycles of the two different cooperation tools, electronic circulation folders and shared workspaces, shows that extensions to the basic components are of different nature. Circulation folders were mainly extended by further functionality, such as electronic signatures or the HTML interface. The usage of shared workspaces has demonstrated the necessity for means that allow a flexible configuration of their behaviour.

The object-oriented paradigm promises to support software design of complex systems since it allows to encapsulate functionality into objects. Reusability of functionality is supported by the mechanisms of inheritance and polymorphism. Several groupware systems are developed in an object-oriented programming language. Their underlying class hierarchy contains classes that support individual work practices (like documents, filing facilities, or tools) as well as classes that support cooperation among the involved partners (as circulation folders or shared workspaces). Some of these groupware systems provide a programming interface to their functionality. The design of specific cooperation support functionality within such a system is usually done by refining these basic classes in derived classes. This approach reveals several disadvantages: Every implementation of a specific cooperation tool results in the extension of the class hierarchy. A flexible reaction to new user requirements is only supported when the underlying programming language allows the modification of the class hierarchy during runtime of the system.

In the following we propose a different approach which is mainly based on the object- oriented concept of composition. This approach provides an infrastructure that allows to enrich the functionality of object instances. The main components are

• CSCW enablers which are service objects that provide basic cooperation support functionality and
• CSCW mediators that encapsulate the interaction of enables attached to an object.

The functionality of an object (like a container) can be configured and extended by attaching enablers to the object that realise additional cooperation support functionality. The mediators role is to administer all enablers belonging to the target object.

The concept offers a broad range of cooperation support functionality each encapsulated in enablers. Just to mention some examples, there are enablers that provide communication facilities or support coordination among different users of the object. This can be done by explicit methods (like access control and locking) or

implicit methods (like awareness mechanisms). Further enablers support object sharing or are used to introduce conventions into the system.

Paying regard to the example of a shared workspace mentioned earlier, a container object designed for the "single-user-case" can be realised with the help of different enablers:

• an access control enabler controls access to the container,
• a member administration enabler allows to invite new members or exclude current members,
• a communication enabler provides communication facilities,
• an event enabler notifies current members of the workspace about ongoing events,
• a history enabler records past events,
• a shared workspace (sws) enabler informs users about the "publicity" of further actions after having entered the workspace,
• a privacy enabler suppresses information about private modifications of objects in the object history,
• a "create-a-share" enabler is activated when a user drags objects out of the container. It informs the users that removing objects out of the container results in withdrawing access for the other members and proposes to automatically leave a share to the object in the container.

Figure 5 shows how the invocation of the add-method of the container object is delegated to the different enablers via the mediator (numbers indicate the sequence of calls). As the example shows, some enablers are activated before the method on the target object are called (like access control). The method on the target object is only invoked in case of a positive result of these pre-processing enablers (access is granted and the user has confirmed the entrance of the shared workspace). Other enablers should only be activated when the method on the target object succeeded (as event notification).

Figure 5: Enablers attached to a container object.

One part of the enabler interface is constant: this part corresponds to the interface of the enabled objects. Its methods specify, how the semantic of object methods on the target object are enriched. They therefore allow to specify cooperation support functionality to specific access situations (when someone opens a document, modifies the document, etc.).

Enablers can enrich the functionality (as sending an event notification), stop execution of the called method (when access is not granted) and invoke new methods.

We introduce the CSCW mediator as the component which encapsulates the interaction of the different enablers. Whenever a method on the target object is called this call is first delegated to the mediator. The mediator maps the incoming method call onto a corresponding method of the enabler interface and iterates through all enablers attached to the target object. Since a modification of the target object also results in a modification of its context, the mediator takes this context into account. The following picture shows the example of deleting a document within in a shared workspace. The deletion of a document results in removing the document from its context formed by its containers. The mediators invoke the corresponding enablers.

Figure 6: Enablers of a target object (memo) and its containers (folder, shared workspace).

This concept allows the configuration of the cooperation support functionality on different levels: the introduction of further enablers allows to adapt system functionality to the work setting, the combination of enablers allows to configure a target object and by deactivating single enabler methods, more fine-tuning can be done.

Figure 7 shows the configuration dialogue to attach enablers to target objects. This dialogue, too, allows to make the configuration visible to every user that has access to this object. In this way, the behaviour of the shared workspace is not hidden anymore in the system but is made apparent to its users. Further information can be found in [Syri, 1997].

Figure 7: Configuration of an object by combining enablers.

Figure 7: Configuration of an object by combining enablers. The example has shown how a shared workspace can be realised with this design concept. The introduction of further coordination supporting enablers may even introduce a turn-taking mechanism and to-do-lists in the workspace. With this

mechanism we can realise the complementary use of circulation folders and shared workspaces that is proposed in the next section.

4.3 Integrated Use of Both Cooperation Tools

Having introduced both cooperation media - electronic circulation folders and shared workspaces - this section shows how both tools complement one another.

The cooperation media realised in the POLITeam system provide each support for a certain type of work process. However, the scenario shows that both types of work are interweaved. For example documents received by a circulation folder need to be discussed or must be supplemented with contributions from others. Thus, both electronic cooperation media must provide easy means to switch between each other and to exchange documents. The combination of both tools provides further possibilities to structure and organize cooperative processes. In the following we will illustrate how shared workspaces can be extended by electronic circulation folders and vice versa.

4.3.1 Electronic Circulation Folders Structure the Flow of Work in a Shared Workspace

Two application areas exist for this. Let us first consider a group that coordinates the production of a document by the use of a shared workspace. Although each member of the group wants to have unlimited read access to the documents in the workspace, they want to coordinate the modifications to the document. This is important when the task requires a sequential order of activities because the input of one user depends on the input of the precessor. To achieve this a share to the document is placed in an electronic circulation folder. The circulation folder is then routed between the members of the workspace (Figure 8, left side). By convention or by the configuration of appropriate access rights, only the user who currently accesses the circulation folder is allowed to modify the documents. With this application the circulation folder provides a turn-taking mechanism for the cooperation within the shared workspace.

Figure 8: Circulation folders route workspace documents.

The same technique can be used to involve people who should not receive full access to the whole workspace. In this case, shares to relevant documents of the workspace are added to a circulation folder and forwarded to the person not being member of the workspace. This allows the use of both tools on the same document to distinguish between users who have unlimited access (the workspace members) and users who receive only limited, sequential access, e.g. for approval processes. This is illustrated by Figure 8 on the right side. It shows the participants involved in the process who are coordinated by the electronic circulation folder and how selected documents are processed by additional participants.

4.3.2 Electronic Circulation Folders Extend Shared Workspaces

A circulation folder can be added to a workspace in order to involve persons for a limited period of time and asking them for a certain contribution. This allows to involve further persons without affecting the circulation path. The sequential cooperative process is extended and cooperation on the content of the circulation folder can take place in parallel.

Figure 9: Extending the sequential flow of a circulation folder by a shared workspace.

For example this enables a user to share a received circulation folder with other users. These are then able to contribute documents that provide additional information to the process. By the provision of a temporary common access to the previously sequential medium, an acceleration of the process can be achieved, if the sequential order is not required at this stage of the process.

Furthermore this technique can be used to give read access to a person during the complete flow of the circulation folder, not limiting the access to a certain stage of the folder. This provides an overview about the ongoing activities.

In this section we have discussed the combined usage of the two POLITeam cooperation media. It is interesting to see that this combination maps to the four modes of knowledge conversion proposed by Nonaka and Takeuchi (Fig. 10).

Figure 10: Four modes of knowledge conversion [Nonaka and Takeuchi, 1995]

Workspaces can be seen as a "free" field of interaction. They allow the users to "socialize" around a process and also to move the tacit knowledge to explicit knowledge. This requires means for the externalization that are provided by the elctronic circulation folder. Thus the workflow component can be regarded as a means of enacting the explicit knowledge contained in the process maps of organizations.

The first example can be seen as using the circulation folder to move from tacit knowledge (every one in the shared workspace knows how the documents have to be produced in terms of content structure and approvals) to explicit knowledge in a circulation folder describing which are the steps the documents must follow in the organizational structure. The second example allows to add to the process a space where to externalize further tacit knowledge not described by the explicit procedure described in the circulation folder.

5 Summary

This paper focussed on the two cooperation media provided by POLITeam: electronic circulation folders and shared workspaces. Whereas the first medium is especially suited to support structured work processes, the latter can be used for less structured ones.

We have presented a ministerial application scenario and shown that most cooperative processes embrace structured as well as unstructured parts. In order to provide suitable cooperation support, both cooperation forms have to be considered.

We have shown that electronic circulation folders and shared workspaces are complementary. Circulation folders can be used to structure subtasks within shared workspaces and to ask non-members for a contribution. Shared workspaces allow to interrupt the flow of a circulation folder for a while and to do work in parallel.

The combined usage of circulation folders and shared workspaces allows a smooth transition between structured and less structured processes. Together they offer a very flexible support of cooperative processes and provide new means for the organization

of cooperative processes. Although the requirements for the development of the basic tools as well as the various extensions were derived from the practical use of the POLITeam system in a German Ministry we believe that presented solutions are applicable for other applications of cooperative knowledge management too.

Acknowledgements

6 References

[Agostini, Michelis, et al., 1996] Agostini, A., G.d. Michelis, M. Grasso, W. Prinz and A. Syri, "Contexts, Work Processes, and Workspaces," Computer Supported Cooperative Work: The Journal of Collaborative Computing, 1996, Vol. 5, No. 2-3, pp. 223-250.

[Bentley and Dourish, 1995] Bentley, R. and P. Dourish, "Medium versus mechanism: Supporting collaboration through customization", in Proc. of Fourth European Conference on Computer Supported Cooperative Work (ECSCW '95), H. Marmolin, Y. Sundblad, and K. Schmidt (eds.), Stockholm, Sweden, Kluwer, 1995, pp. 133-148.

[Glance, Pagini, et al., 1996] Glance, N.S., D.S. Pagini and R. Pareschi, "Generalized Process Structure Grammars (GPSG) for Flexible Representations of Work", in Proc. of Conference on Computer Supported Cooperative Work (CSCW'96), M.S. Ackerman (eds.), Boston, MA, ACM Press, 1996, pp. 180-189.

[Gräther, Prinz, et al., 1997] Gräther, W., W. Prinz and S. Kolvenbach, "Enhancing Workflows by Web-Technology", in Proc. of GROUP'97 International Conference on Supporting Group Work, S. Hayne, M. Pendergast, et al. (eds.), Phoenix, AZ, ACM Press, 1997.

[Grudin, 1994] Grudin, J., "Groupware and Social Dynamics: Eight challenges for developers," Communications of the ACM, 1994, Vol. 37, No. pp. 92-105.

[Karbe, Ramsperger, et al., 1990] Karbe, B., N. Ramsperger and P. Weiss, "Support for Cooperative Work by Electronic Circulation Folders", in Proc. of Conference on Office Information Systems, F.H. Lochovsky and R.B. Allen (eds.), Cambridge, MA, ACM Press, 1990, pp. 109-117.

[Klöckner, Mambrey, et al., 1995] Klöckner, K., P. Mambrey, M. Sohlenkamp, W. Prinz, L. Fuchs, S. Kolvenbach, U. Pankoke-Babatz, and A. Syri, "POLITeam: Bridging the Gap between Bonn and Berlin for and with the Users", in Proc. of ECSCW '95, Stockholm, Kluwer, 1995, pp. 17-32.

[Kreifelts, Licht, et al., 1984] Kreifelts, T., U. Licht, P. Seuffert and G. Woetzel, "DOMINO: A system for the specification and automation of cooperative office processes", in Advances in Mocroprocessing and Microprogramming, Proc. EUROMICRO 84 (Copenhagen, Aug. 84), B. Myhrhaug and D.R. Wilson (eds.), North-Holland, Amsterdam, 1984, pp. 33-41.

[Kyng, 1994] Kyng, M., "Experience with Participative Application Development", in Proc. of IFIP 13th World Congress, K. Brunnstein and E. Raubold (eds.), Elsevier Science B.V. (North Holland), Vol. 2, 1994, pp. 107-119.

[LinkWorks, 1995] LinkWorks, LinkWorks User Manual, 1995, Digital, URL: http://www.digital.com/info/linkworks.

[Mark and Prinz, 1997] Mark, G. and W. Prinz, "What happened to our Document in the Shared Workspace? The Need for Groupware Conventions", in Human-Computer Interaction INTERACT'97, S. Howard, J. Hammond, and G. Lindgaard (eds.), Chapman&Hall, London, 1997, pp. 412-420.

[Nonaka and Takeuchi, 1995] Nonaka, I. and H. Takeuchi, The Knowledge Creating Company, Oxford University Press, 1995.

[Pankoke-Babatz, Mark, et al., 1997] Pankoke-Babatz, U., G. Mark and K. Klöckner, "Design in the PoliTeam Project: Evaluating User Needs through Real Work Practice", in Proc. of Design of Interactive Systems Conference, Amsterdam, 1997.

[Prinz and Kolvenbach, 1996] Prinz, W. and S. Kolvenbach, "Support for Ministerial Workflows", in Proc. of Conference on Computer Supported Cooperative Work (CSCW'96), M. Ackermann (eds.), Boston, MA., ACM, 1996, pp. 199-208.

[Rivest, Shamir, et al., 1978] Rivest, R., A. Shamir and A. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, 1978, Vol. 21, No. 2, pp. 120-126.

[Schael and Zeller, 1993] Schael, T. and B. Zeller, "Workflow Management Systems for Financial Services", in Proc. of Conference on Organizational Computing Systems, S. Kaplan (eds.), Milpitas, California, ACM Press, 1993, pp. 142-153.

[Schneider, 1993] Schneider, W., SeCuDE - Overview, GMD-Arbeitspapiere 775, Bonn, GMD, 1993.

[Sohlenkamp, Fuchs, et al., 1997] Sohlenkamp, M., L. Fuchs and A. Genau, "Awareness and Cooperative Work: The POLITeam Approach", in Proc. of HICCS'97, Maui, Hawaii, IEEE Computer Society Press, 1997, pp. 549-558.

[Syri, 1997] Syri, A., "Tailoring Cooperation Support through Mediators", in Proc. of ECSCW'97: Fifth European Conference on Computer Supported Cooperative Work, H. Hughes, W. Prinz, et al. (eds.), Lancaster, UK, Kluwer, 1997, pp. 157-173.