Two complementary tools for the cooperation in a ministerial environment
GMD-German National Research Center for Information Technology, Germany
GMD-German National Research Center for Information Technology, Germany
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
Key Words: CSCW, groupware, workflow, shared workspaces, design
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 POLITeam1 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
 POLITeam is funded by the German Federal Ministry of Education, Science, Research, and
Technology in the POLIKOM framework. A general overview of POLITeam can be found in
[Klöckner, Mambrey, et al., 1995].
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
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
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.
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
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
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
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.
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.
184.108.40.206 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].
220.127.116.11 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.
18.104.22.168 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.
22.214.171.124 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
126.96.36.199 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
- 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
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
- an access control enabler controls access to the container,
- a member administration enabler allows to invite new members or exclude current
- 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
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
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
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
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.
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
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.
We give special thanks our POLITeam collegues and to the anonymous reviewers for
their valuable comments on this paper.
[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.