Tailoring Groupware:
The Cooperative Hypermedia Approach
Weigang Wang and Jörg M. Haake
GMD - German National Research Center for Information Technology
IPSI - Integrated Publication and Information Systems Institute
Dolivostr. 15, 64293 Darmstadt, Germany
E-Mail: {wwang, haake}@darmstadt.gmd.de
Abstract.
Tailoring groupware has to deal with adapting properties of a shared information space
as well as with adapting properties of the cooperation support to the group's needs. In this
paper, an approach for tailoring both aspects of groupware in an integrated fashion is proposed. This approach uses cooperative hypermedia as a unifying representation of shared
information structures, functionality, and the coordination medium of a shared application.
It enables cooperative definition of shared information structures, shared process models and
their access models not only before collaboration starts, but also on the fly, when emergent
processes evolve. The proposed approach addresses tailoring at all stages of the development
and use of a groupware application. A prototype system called CHIPS is presented and different possibilities of tailoring in CHIPS are discussed. Examples of CHIPS demonstrate that
the cooperative hypermedia approach to tailoring groupware can support the adaptation to
different evolving tasks and processes performed by changing teams.
Keywords: Cooperative hypermedia, Tailoring, Meta-model, Group process, Information
structure, Flexibility, Access control
1. Introduction
Groupware supports a group of team members in performing a common task
by providing an interface to a shared environment (Ellis and Rein, 1991).
Since the variability of co-operation styles, common tasks, and work processes is extremely high, it is difficult for groupware designers to develop
groupware that matches the needs of every usage situation.
A similar problem exists for applications aiming at individual users. In
the past, one approach to overcoming this problem has been to allow tailoring of the application's functionality. Tailoring is based on the general
applicability of an application and allows end users to add specific support
for a certain usage situation. Usually, applications are tailored with respect
to their behavior in terms of their user-interface, the information structures
(e.g., templates or Document Type Definitions) and operations (e.g., macros)
provided. This enables users to adapt the functionality of the application to
their specific needs.
c 1998 Kluwer Academic Publishers. Printed in the Netherlands.
jcscwf.tex; 23/11/1998; 18:36; p.1
2
Weigang Wang and Jörg M. Haake
In the case of groupware one can argue that tailoring becomes more
difficult: First, tailoring becomes a group activity. It must not only allow
adaptation to individual needs but to the needs of individual team members
and the whole team at the same time. Second, tailoring cannot be confined
anymore to the structure, presentation and functionality of the (now shared)
information space. It must now also provide means for tailoring groupware
support for the group process itself. Furthermore, the above two dimensions
of tailorability in groupware systems, i.e. the properties of the shared information space and the properties of group process support, need to be addressed
in an integrated fashion. A solution needs to provide tailorability on both
dimensions in a consistent way. Finally, such a tailorable groupware system
must be easy to use so that the intended user community can actually tailor
the system frequently during its use.
In this paper, we discuss a solution to the groupware tailorability problem and present an example system illustrating this approach. The main ideas
in this approach can be characterized as follows:
1. Use of a cooperative hypermedia system for providing a shared workspace.
This hypermedia system provides end-user ad-hoc modifiable schemata
for representing the shared information space. These schemata are also
used to define the operations on the shared information space. This enables groups of users to adapt information structures and operations to
their task at hand. Furthermore, since all the tools of the hypermedia system are cooperative, teams can define and manipulate their information
space together.
2. Group process support is provided as part of the cooperative hypermedia
system. This is done by modeling group processes (e.g., workflow like
co-ordination structures) as hypermedia structures. This way, groups can
define their work processes in a cooperative manner, change processes
ad-hoc and even develop emerging processes. Furthermore, groups can
execute the group process cooperatively.
3. In addition to process support - which is used mainly for co-ordination
of group members or subgroups - a flexible role-based access model has
been added. By automating changes of the access structures and by simplifying the use of the access model by end-users, teams can easily deal
with changing team composition and changing roles of team members.
Together, these three components of our approach enable the resulting
cooperative hypermedia system to offer tailorability on both dimensions: the
information space dimension as well as the group process support dimension.
Thus, a more integrated view of the tailoring activity is now possible. The
remainder of this paper is organized as follows: In the next section we present
jcscwf.tex; 23/11/1998; 18:36; p.2
Tailoring Groupware: The Cooperative Hypermedia Approach
3
a more detailed analysis of the groupware tailorability problem. Section 3
proceeds with an analysis of previous work. In section 4 we introduce our
approach and illustrate it by CHIPS, an example system implementing our
approach, and its techniques for tailoring. Section 5 discusses tailoring of
different aspects of groupware in an integrated fashion. Finally, we compare
our approach to related work and discuss future work.
2. Analysis of groupware tailorability
Tailoring groupware can help to overcome certain problems that groupware
faces in a dynamic environment: First, since groups may change dynamically
(see, for example, virtual organizations) and the joint task of the team may
also change - or even evolve - over time, groupware needs to be adapted in
order to continue to provide optimal support. Second, since these factors are
dynamic in nature and not known beforehand, end users must be able to adapt
groupware to their needs. Tailoring seems a useful approach to address these
problems.
2.1. A S CENARIO
We begin the analysis of groupware tailorability with a simplified scenario
describing a collaboration process. Imagine a group of people which form
a new project team. There is a project manager and several team members.
Since this is not a full-time project, all members are also working on other
tasks in parts of their time. The part-time nature of the project will certainly
lead to mixtures of asynchronous and synchronous collaboration. The team
task is to select appropriate software for a larger organizational unit. Thus, a
co-decision making process is at hand. What impact will possible decisions
of the team, with respect to their style of collaboration and their approach to
solving the task, have on the collaboration functionality required and thus on
the tailorability needed in an ideal collaboration environment?
Let's assume the team meets at the beginning to discuss their approach.
In such a meeting they would create an outline of their next steps. Possibly, these could be (1) creation of ideas and requirements, (2) discussion of
alternative solutions, and (3) making a decision.
At the beginning, the creation of ideas and requirements could be done
using a brainstorming approach where team members contribute their ideas
either asynchronously or synchronously to a shared workspace. Simple functionality of the shared workspace may suffice at this stage since only different
ideas or contributions need to be separated and viewed.
The next step requires some more advanced support. Discussing alternative solutions needs means for identifying solutions and associating them with
jcscwf.tex; 23/11/1998; 18:36; p.3
4
Weigang Wang and Jörg M. Haake
ideas and for representing and relating solutions, arguments and positions
(e.g., in the form of an IBIS structure (Conklin, 1988)). Thus, the shared
workspace would now need to offer corresponding support. Note, that the
need for exactly this kind of support (e.g., the IBIS structure) arises from
the nature of the task and their work plan. Other tasks and other teams
might come up with different requirements! Thus, tailoring is needed to
adapt the shared workspace to the group's needs. In our scenario the team
would now tailor the shared workspace on-the-fly to provide appropriate IBIS
functionality. This can be regarded as tailoring for situated work.
The transition to the third step (i.e. decision-making) again changes the
required support from the collaboration environment. Until now, a manually
coordinated work procedure (where dates and progress were negotiated informally via e-mail and direct communication) was adequate for the team.
Now, the group decides to work more asynchronously on comparing different alternatives. Thus, more formal coordination is required. The group
decides to define different roles and a more formal work process connecting
different subtasks to form a whole decision process. This work process is
actually not defined ad-hoc and once-and-for-all but emerges over a period
when team members work on the tasks, discover missing steps, inadequate
procedures or wrong assignments, and adapt the process structure on-thefly. Since changes have impact on the whole team, they need a mechanism
that helps to perform these adaptations cooperatively. During their work, the
collaboration environment needs to support their collaboration by (i) helping them to coordinate their efforts by informing actors about next possible
steps, (ii) forwarding information between steps, (iii) enabling adaptation of
process structure, (iv) facilitating cooperation among multiple team members
working on the same task or sharing the same data while working on different
tasks, and (v) maintaining consistent states of the shared workspace (also by
ensuring that only valid changes/actions corresponding to the respective team
member's role occur). Since the required support again depends on the team's
task and work style, tailoring for emergent processes is required.
Initially, access control for the lower structured process steps was less
important since the structure was more emergent. Now, the collaboration
process in our scenario (which started with low structure and very informal,
and which included increasing process structure in steps 2 and 3) becomes
more formal. In order to maintaining the integrity of the process definition,
access control on the shared workspace is required.
Throughout the work process described in the above scenario, different steps require different support for tailoring the collaboration support.
Furthermore, since each team might have their specifics leading to different
tailoring needs no single predefined collaboration environment could provide
optimal support to all these teams. Thus, the need for tailoring for each in-
jcscwf.tex; 23/11/1998; 18:36; p.4
Tailoring Groupware: The Cooperative Hypermedia Approach
5
dividual team arises. In the next subsection, we discuss the more technical
requirements of tailoring a groupware application.
2.2. W HAT DOES
TAILORING MEAN FOR GROUPWARE ?
Tailoring groupware primarily means to adapt different properties of the
shared environment and of the interface to this environment. These properties
include:
Design of the shared information space
Coordination means
Organizational context and access control
User interface to the shared environment
In the following, we discuss requirements on tailoring each of these properties
of groupware.
2.2.1. Design of the shared information space
The design of the shared information space provided by a groupware application is determined by its structure (i.e. types of objects and relationships
among them) and by the operations (i.e. functions and constraints) provided
on these objects and relationships. Obviously, structure and operations need
to match the requirements of the task at hand (as exemplified by the IBIS
structure added in the shared workspace of our scenario). Due to the large
variability present within the set of possible tasks, end-users need to be able
to adapt the structure and operations to their needs. Furthermore, since different sub tasks might require different structures and operations, corresponding
sub spaces of the overall information space should be supported. In order to
deal with emerging and/or changing tasks, dynamic changes of structure and
operations as well as additions and transformations of sub spaces need to be
supported. In our scenario, reusing parts of the resulting structures of earlier
steps as data to be used in process steps added later may serve as an example
here.
2.2.2. Coordination means
Coordination enables a team to tackle the common task in an orderly manner.
Thus, there is a need for some kind of process support. Teams might adopt
many different style of coordination. The selection of the `right' coordination
style for the group depends, e.g., on the task at hand, the current task phase,
the working style of the group, the individual members' experience level,
etc. Possible coordination styles (or means) range from strict, pre-planned
jcscwf.tex; 23/11/1998; 18:36; p.5
6
Weigang Wang and Jörg M. Haake
workflow to ad-hoc or emerging workflow to informal coordination. Coordination styles adopted by a team are reflected in the group's task structure,
the assignment of sub groups to sub tasks, the distribution of authority etc.
This effect showed in our scenario when different steps or phases required
different cooperation support. Furthermore, different styles might be used for
different sub tasks. This can lead to a mixture of different coordination means
in an overall group work process, each one suited to it's corresponding sub
task and sub group. Thus, there is a need to support different coordination
styles as well as transitions between them.
2.2.3. Organizational context and access control
Organizational context and access control are used in groupware applications
to enable groups to deal with changing members - potentially from different
organizations - and to maintain trust and privacy within a shared environment.
Access control can be used to restrict access to those trusted and to protect
privacy. In our scenario this became more important when dealing with a
more formal process. In groupware dealing with changing environments, the
specification of possible access to a shared information space and of coordination styles cannot be based on specifying individuals anymore. This is
due to the complexity involved in adapting access control structures to new
or changing group members.
2.2.4. User interface to the shared environment
The user interface to the shared environment defines the presentation and
interaction means for displaying and interacting with the shared information
space. Here, tailoring must facilitate the accommodation of individual preferences as well as simultaneously maintaining a shared space. Otherwise,
if shared objects are displayed and manipulated in totally different ways
team members might not be able to adequately communicate with each other
on such objects. Thus, some kind of consistent shared interface must be
maintained for certain phases of group work.
2.2.5. Dependencies between tailoring different properties
From above discussion it can be seen that the above properties are not
independent from each other. Examples for these interdependencies include:
changes in the cooperation style might require changes of access control
(as, e.g., changing from synchronous to asynchronous cooperation may
require other techniques for coordinating actions);
changes in group membership might impact the coordination style;
changes of the task structure might require corresponding changes of
the information structures used in different sub tasks etc (as, e.g., seen
jcscwf.tex; 23/11/1998; 18:36; p.6
Tailoring Groupware: The Cooperative Hypermedia Approach
7
in the scenario when new steps required new functionality for decisionmaking).
Thus, an integrated view of tailoring is required!
3. Previous work
Related work can be found in a number of areas. Initially, tailoring was raised
as an issue when designing information systems in general. Here, tailoring
the user interface and functionality of single user applications are examined.
However, these approaches neglect the problem of tailoring group process
support. In the following, we discuss approaches that are more closely related
to tailoring groupware applications.
Trigg (Trigg et al., 1987) identified four ways that a system can be
adaptable: a system is flexible (providing generic objects that can be used
differently), parameterized (selecting among a range of alternatives), integratable (integrated with other facilities and connected to remote facilities),
and tailorable (changing the system itself, say by specializing and adding
functionalities).
Hypermedia systems provide flexible ways of structuring an information space. Different approaches to adapting the information space to
specific needs can be distinguished: Many hypermedia systems support predefined types created by system developers, see e.g., SEPIA (Streitz et al.,
1992; Knopik and Bapat, 1994), gIBIS (Conklin, 1988), and PHIDIAS (McCall et al., 1990). However, since end users are usually not system developers,
tailoring by end users is not supported by these systems. Another approach is
to provide certain formal representations to allow knowledge structures to be
defined by schema designers. Examples are Aquanet (Marshall et al., 1991)
and MacWeb (Nanard and Nanard, 1991). These systems are closer to end
users, but still require specially trained schema designers. A third approach is
to support templates (i.e. parametrized adaptation as provided by NoteCards
(Trigg et al., 1987)). Templates capture a reusable hypertext structure which
can be defined and used by end users. However, the components of a template
are constrained to those object types provided by the system. Thus, tailorability is limited. Finally, in systems like HyperCard (Goodman, 1987), users
can tailor the system by using its internal scripting language. This, however,
requires the end user to become a programmer. In most of these systems, to
effectively use a scripting language takes a fair amount of expertise (Halasz,
1991). Although many hypertext systems have some built-in tailoring facilities to allow people to adapt the system to their particular needs, the tailoring
facilities were really aimed at system implementors and programmers. As
Halasz pointed out, the challenge is to bring tailorability into the hands of the
non-programmer user (Halasz, 1991).
jcscwf.tex; 23/11/1998; 18:36; p.7
8
Weigang Wang and Jörg M. Haake
Cooperative hypermedia systems support asynchronous or synchronous
sharing of hypermedia spaces. Usually, the process support provided is limited to one or a few cooperation modes, as in SEPIA (Haake and Wilson,
146; Streitz et al., 1992), Aquanet (Marshall et al., 1991), or KMS (Akscyn
et al., 1988), and cannot be tailored by end users. Trellis used a Petrinet-based model to represent document structures with browsing semantics,
cooperation protocols, and software processes (Furuta and Stotts, 1994).
Here, users capable of defining Petri-nets can define new cooperation behavior. Finally, in the versioned cooperative SEPIA system (Haake and Haake,
1993) a group can define a shared task structure and execute the shared task
on the shared information space. Integrated versioning support enabled more
fine-grained access to and parallel work on the shared information space.
However, there was no automatic execution support as, for example, provided
by workflow systems.
Research in the CSCW area related to tailoring can be roughly divided
into two groups: Firstly, there are studies on how tailoring and adaptation of
groupware works in the field. Secondly, there are some technical approaches
to provide support for tailoring in groupware applications.
Trigg et al. (Trigg and Bodker, 1994) analyzed how people working in
a governmental labor inspection agency tailor their shared PC environment.
Their study shows that tailoring is a collective process, reshaping standard
technologies in use. They advocate interactive tailoring environments and
abstract systems thinking, which support the tailors' need to move toward
abstraction and systematization. Trigg et al. believe that the cooperation between local developers (tailors) and systems developers offers a valuable and
challenging opportunity for the years to come.
Okamura et al. (Okamura et al., 1994) argue that well-managed mediation may be a useful mechanism for shaping technologies to evolving
contexts of use, and that it extends our understanding of the powerful role that
intervenors can play in helping CSCW applications succeed. Rogers (Rogers,
1994) examines the co-evolution process involved in tailoring a CSCW system to fit in with the current organizational structure, whilst concurrently
adapting the working practices to enable the system to support collaboration.
The more established a working practice has become, the more resistance
there is to changing it. Likewise, the more radical a change proposed to adapt
a CSCW system is, the more resistance there is to accepting it.
Some more technical approaches for tailoring groupware have emerged
in the past: One of these is Oval (Malone et al., 1992). Oval is a messaging
system with four basic abstractions: Objects, Views, Agents, and Links. Oval
has a visual programming language for a form of end-user programming. An
application can be constructed by defining a set of objects, creating agents
to trigger behaviors on input or computation, and providing an appropriate
set of visualizations. Oval allows neither new abstractions nor new forms of
jcscwf.tex; 23/11/1998; 18:36; p.8
Tailoring Groupware: The Cooperative Hypermedia Approach
9
existing abstractions (such as a new view) to be introduced into the system.
Since Oval supports asynchronous collaboration via message exchange using
a single-user user interface, sharing and collaboration remain largely outside
its domain.
Prospero (Dourish, 1995) applies computational reflection to the design
of a CSCW toolkit. Prospero provides the flexibility for application programmers to manipulate, control and specialize its toolkit components and
mechanisms to meet the need of a wide range of CSCW applications. Prospero supports two levels of programming. The base level programming makes
use of four abstractions (streams, actions, promises, and guarantees) provided
by Prospero. Meta level programming addresses how the abstractions are realized. The meta level programming employs the metaobject protocol (MOP)
technique. CSCW programmers can tailor the toolkit behavior to their specific
needs. The tailorability it supports is largely targeted for programmers, rather
than end-users.
In summary, one can state that there is no approach that facilitates tailoring of groupware by end users and which at the same time specifically
addresses tailoring properties of the shared information space and properties
of the group process support. In the next section we introduce our approach
to this problem.
4. CHIPS and its techniques for tailoring groupware
In this section, we first introduce CHIPS, its modeling concepts, and three
levels of abstractions of the concepts. Then, methods, tools, and examples of
tailoring across the three levels are introduced.
4.1. CHIPS
IN A
N UTSHELL
CHIPS stands for Cooperative Hypermedia Integrated with Process Support.
It aims at providing flexible process support in a cooperative hypermedia
environment. Flexible process support includes
support for defining processes with different degrees of formality (from
manually coordinated, to suggested but modifiable, and to mandatory
scheduled processes),
support for enacting these processes, and
support for changing processes and developing emergent processes.
In addition to asynchronous cooperation, team members can also work
together synchronously in defining and executing cooperative processes.
jcscwf.tex; 23/11/1998; 18:36; p.9
10
Weigang Wang and Jörg M. Haake
The high-level abstractions of the CHIPS system are cooperative hypermedia based active spaces, whose modeling components include typed
hypermedia objects (nodes, links, multimedia objects, and node content pages
(composites)), objects for a role-based organizational context (people, teams,
and roles), and objects providing the linkage between an activity space and
its user interface (sessions).
A hypermedia based activity space provides task-specific hypermedia
structures and operations. A process space is an activity space that can represent and execute processes. A role-based organizational context includes
role-based organization structures and role-based access control upon activity
spaces. A session provides a run-time context for team members to coordinate
their access to a shared activity space. These four concepts correspond to
the four high level adaptable groupware properties identified in the previous
analysis section. Next, we describe each of them in more detail.
4.1.1. Activity Space
The basic elements of the hypermedia-based activity space model are links,
nodes, node content pages, and other multimedia objects. This model describes an activity space from three semantic dimensions: structural, relational, and computational. Structural semantics describe the graph type of a
hypermedia structure. Along this dimension, links are classified into two categories: organizational and referential. Organizational links are used for those
relations which have structural constraints, such as a acyclic graph constraint
required for `is a' relation and `part of' relation. Referential links are used for
cross-reference type relationships. They do not have structural constraints.
Relational semantics describe the relationship between typed hypermedia objects. Along this dimension, links and nodes are further classified into many
application-specific semantic types, and the allowable relationships between
them are specified. Computational semantics define task-specific actions or
operations upon hypermedia objects.
Figure 1. Logical structure of an activity space
jcscwf.tex; 23/11/1998; 18:36; p.10
Tailoring Groupware: The Cooperative Hypermedia Approach
11
The logical structure of an activity space is illustrated by Figure 1. Large
squares are node content pages (composites), and small squares within pages
are node representations, which in this model are anchors of embedded links
that point to the content pages of the nodes. The straight arrows between
node representations are independent links. The straight dotted arrow lines
are embedded organizational links, and curved arrow lines are embedded
referential links. Also, other multimedia objects can be included on a page.
The shade under a page indicates that there is a page schema for each page.
The structure of a composite is determined by its root node page schema,
because the structures of its components are recursively defined along embedded organizational links. For details on the activity spaces model see also
(Wang and Haake, 1997).
A cooperative activity space provides multiple users with synchronous
or asynchronous access to a shared hypermedia workspace (Streitz et al.,
1992). In addition to access, cooperative activity spaces provide group
awareness by showing collaborators' presence and activities in the shared
workspace. Our cooperative activity space is built on a shared information
space, which is based on the COAST cooperative application systems toolkit
(Schuckmann et al., 1996).
4.1.2. Process Space
Our approach to process modeling is to integrate task and process computational semantics into the cooperative hypermedia based activity space. As
both the structural and relational semantics are directly applicable to process
structures, what is needed is to incorporate task related semantics, such as
state, time, and state transition semantics into hypertext nodes, and to incorporate control flow and data flow semantics into hypertext links. Thus, a
process is represented as a set of task nodes connected by process links. These
form a hypermedia composite consisting of potentially nested task nodes and
process links between task nodes. Actors are identified by an attribute of a task
node. The process computational semantics, such as those reflected in the task
node types and process link types, are assigned to typed hypermedia nodes
and links at the process definition phase. They become part of the properties
of the typed nodes and links to be used for creating process space instances.
As the process space is a special case of activity space, the distinction between information space and process definition is blurred. They are
two views on a unified hypermedia model. This enables smooth transitions
between these two views, and supports cooperative work on defining and
manipulating process and information structures in an integrated fashion. For
details on hypermedia-based process modeling also see (Wang and Haake,
1998).
jcscwf.tex; 23/11/1998; 18:36; p.11
12
Weigang Wang and Jörg M. Haake
4.1.3. Role-based Organization Context and Access Control
A role-based organizational context in CHIPS includes people, teams (a set of
people working in the same work unit or project), organizational roles (a set
of people having the same job function), the relationship among them, and the
role-based access control upon activity spaces. In CHIPS, individuals, teams,
and organizational roles are uniformly modeled as roles (three types of the
role objects). The user authorization is specified using two independent tools:
an editor that assigns users to roles, and a dialogue box which assigns access
permission for objects (or object types) to roles. The team concept plays an
important part in our access model. It is used to identify relevant people from
a set of people taking the same organizational roles. A user can perform an
operation on an object, only if he or she belongs to an organizational role
having such an access permission to the object (or the type of the object) and
at the same time belongs to a team working on the object.
The essence of role-based access control is that permissions are assigned
to roles rather than to individual users. Users acquire these permissions by
virtue of being assigned membership in appropriate roles (Sandhu and Samarati, 1996). With such a role-based approach, users can be easily reassigned
from one role (or team) to another without modifying the underlying access structure. Roles can be granted new permissions as new applications
and actions are incorporated, and permissions can be revoked from roles as
needed. This provides the necessary support for dynamically adapting access
permissions for changing teams.
4.1.4. Sessions and User Interface Linkage
The linkage between activity spaces and their user interface is provided
by session objects. Session objects in CHIPS are persistent. They register
the participating users of a session for providing group awareness, control
the coupling of the shared aspects of participating browsers, and provide a
user interface (session browsers) for manipulating shared objects in activity
spaces. The aspects to be coupled or decoupled may be user interface aspects
(such as positions of scrollbars) or hypermedia object aspects (attributes).
When an interface aspect is coupled via a session, all participating browsers
will have equal access to it and share the same view of and control on it.
Hypermedia object aspects can be coupled via session with two options: either to let participating browsers directly access individual object instances,
or indirectly affect the instances by accessing their type definition. The former option will only affect one object instance; while the later will affect all
instances of the same type. In either case, the dynamically updated views of
the object instances will be shared by all participating browsers. The tailoring
of the coupling of the shared aspects in a session can be done modifying its
coupling attribute list (i.e., a list of name and value pairs). In the attribute list,
the names are the attributes to be coupled and the values may be `user' , `ses-
jcscwf.tex; 23/11/1998; 18:36; p.12
Tailoring Groupware: The Cooperative Hypermedia Approach
13
sion' , `instance' , and `type' . These values provide parameters for the access
operations.
4.2. I MPLEMENTATION T ECHNIQUES
Since it becomes relevant in later sections, a brief introduction to the COAST
cooperative application systems toolkit and some CHIPS implementation details are provided as follows. COAST provides means for representing shared
artifacts, maintaining consistent replicas, and accessing shared objects via
session objects (Schuckmann et al., 1996). COAST is a cooperative modelview-controller framework. Whenever an aspect of a model changes, its view
will be dynamically updated in all its session browsers. In addition to the
normal class inheritance hierarchy, COAST provides a prototype inheritance
hierarchy among the instances of a class. All the CHIPS hypermedia object
classes are subclasses of a prototype class, which in turn is a subclass of
the COAST Model class. Corresponding to each of the hypermedia object
classes, there are at least a view class and a controller class that are subclasses of the COAST View and Controller classes. Using this framework,
CHIPS inherits all the cooperation support provided by the COAST toolkit. A
prototype is an initialized object that can be used as a template (type) for new
objects (Tyugu, 1991). New object instances created from prototypes only
need to initialize those attributes whose values differ from the attribute values
of their prototypes. For the prototype mechanism to work, for each class, at
least one base prototype has to be created. The search for an attribute value
starts at a given level where the concerned instance is located in the prototype
inheritance hierarchy and then goes to higher levels, until a valid value (not
nil) is found. An instance at a lower level of the hierarchy may overwrite an
inherited attribute value, or may switch back to its default inherited value by
setting a nil value to it.
The activity space modeling makes extensive use of the prototype mechanism to model different types (i.e., semantic types) of objects in the same
class. For instance, `Red scribble' and `White scribble' may be two semantic
types of a scribble object class. A page prototype is determined by the component object prototypes that are allowed in this page prototype. For example,
a page type `Chalkboard' can be defined by setting its color to `black' and
setting light colors to all the component object prototypes (such as the `Red
scribble' and `White scribble) allowed in the page type (i.e., page schema).
4.3. TAILORING T ECHNIQUES
For each of the modeling components (or objects) identified in its cooperative
hypermedia model, CHIPS provides three levels of abstraction. In a topdown order, they are meta-models, models, and instances. Abstractions at the
meta-model level are `classes' and `base prototypes' which are specialized
jcscwf.tex; 23/11/1998; 18:36; p.13
14
Weigang Wang and Jörg M. Haake
components from our COAST toolkit. The abstraction at the model level
are `prototypes' customized from the base prototypes or any other existing
prototypes. The abstraction at the instance level are `instances' of prototypes. These three levels of abstractions correspond to three levels of tailoring
targeted for different users. Tailoring at meta-model level is performed by
programmers. Tailoring at instance level is performed by end-users. Tailoring
at model level also targets end-users.
Tailoring and extending often happen hand in hand. When tailoring at
one level is short of certain constructs, an extension at its higher level is
required. In the reverse top-down order of meta-model definition, model definition, and instantiation, a need for tailoring often arises at the bottom level.
If the need cannot be met there, modification at its higher level is needed. If
the need can still not be met at the model level, then extensions need to be
done at the top meta-model level. Since multiple users work cooperatively on
the shared information space, tailoring becomes a cooperative activity among
users at the same level or across levels.
In the following subsections, we present methods, tools, and examples
to show how tailoring is supported at each of the above mentioned levels.
4.3.1. Tailoring at the meta-model level
Methods for tailoring at the meta-model level are based on the COAST framework. The base prototypes for each class of hypermedia objects are created by
application developers who understand the internal structure of the objects.
Also a set of computational semantics is developed which may be assigned
to a prototype in a model definition (by assigning attribute values related
to computations). New object classes (either models, views, or controllers),
their attributes and operations can be added within the framework. New base
prototypes (the root instances in prototype hierarchies) can be created with
a programmer-oriented Prototype Editor. Tools at this level include the the
COAST class libraries and the Prototype Editor. See (Schuckmann et al.,
1996) for more details.
4.3.2. Tailoring at the model level
At the model level our proposed method is based on examples. These allow
ordinary (non-programmer) users to create and tailor models by sketching
an example hypermedia structure. Using this method, a set of application
specific prototypes are tailored from the base prototypes defined at the metamodel level. Attribute values related to structural and relational constraints
can be set (in dialogue boxes) to newly created prototypes for triggering
consistency checking when instances are created from them. Attribute values
related to computations can be assigned to (or removed from) newly created
prototypes to enable (or disable) certain predefined operations. The attribute
values assigned at this level to a page type (schema) or its component proto-
jcscwf.tex; 23/11/1998; 18:36; p.14
Tailoring Groupware: The Cooperative Hypermedia Approach
15
types will become part of their properties. These properties will be shared by
all instances created from the prototypes.
Note, an activity space schema is defined by its root page type, which
in turn is determined by its component prototypes, the relationship among
these types, and the computational properties attached to the types. Therefore,
an activity space schema can be created and tailored by tailoring each of
its component types out of the base prototypes and then assigning attribute
values (such as those for relationship, constraints, presentation styles, taskrelated properties, and access rights) to the newly created types.
After an activity space schema is defined, a new activity space instance
can simply be created by duplicating the example hypermedia structure. This
will lead to a completely initialized hypertext structure that the users can
then adapt to their needs. However, it is also possible to create an instance
directly from the schema. This will lead to an empty hypermedia workspace
to start with. Users can then create their hypermedia structure and content on
the fly. In any case, the constraints defined by the schema will be enforced
by the system. Thus, only valid hypermedia structures can be created. Users
can also create an activity space instance from any existing activity space
instance using a copy-as-template operation. This is possible because every
activity space instance can serve as a template.
In CHIPS, two tools have been implemented to support ordinary users
in applying the above outlined tailoring methods: the schema editor and the
flexible editor. The user interface of each tool has seven major areas (see
Figure 2): At the top is a title bar, which presents the name of the tool, the
name of the current node and the type of the current page. Under the title bar
is a system logo and a list of users (represented by pictures) who are currently
working together on the same page. On the right-hand side is the current node
label whose color indicates the state of the current task node. The largest area
in the middle displays the content of the current page. To the left is a palette
of tools for navigation, editing, and task-related triggers. On the right is a
palette of hypermedia object types that are allowed in the current page.
There are two ways of creating an object: either using a creation operation triggered by a menu or using a creation operation activated by using
the palette. The object creation operations activated with a menu selection
can create new types and may widen linking constraints of a hypermedia
structure. The object creation operations activated with the palette create instances of the selected object type (for the purpose of creating a meaningful
example, which may have multiple objects of the same type). The object
creation activated from the palette has few dialogs to complete, because the
type information has been already defined when the types are first created.
In the session objects of the schema editor and the flexible editor, some
attributes of objects are coupled with the prototypes of the objects, so that
their values and views can be shared by all instances created from them.
jcscwf.tex; 23/11/1998; 18:36; p.15
16
Weigang Wang and Jörg M. Haake
Figure 2. CHIPS user interface layout
These attributes include 1) semantic type related attributes, such as `type' , 2)
constraint-related attributes, such as `defaultPageType' for a node prototype,
3) presentation style-related attributes, such as `color' , and other attributes
that need pre-defined default values such as `accessRights' . Changes to an
example page (and the consequent changes to page prototypes or component
prototypes of a page prototype) may affect all its instances. For example,
changing the background color of an example page will change the background color of all its instance pages; and adding a link of a new type in
a page of the example document would make this link available in all the
corresponding page instances.
Next, we discuss the two tools for tailoring at the model level in more
detail.
The schema editor: In many situations a good example can make complicated things easier to understand. If a user has a clear idea about the
kind of document type he or she wants, it should be easier for him or her
to create a sample document in textual and graphical representations than
to create an abstract expression of a document type in a formal language.
With the example-based method, users create a simple but comprehensive
sample hyperdocument in the schema editor, and the system automatically
extracts schema knowledge from it to define an activity space. Actually, this
extraction is done through coupling the schema related aspects with the object
prototypes via the session object of the session browser (the schema editor).
Whenever an attribute value is assigned to an object on the user interface, the
value goes to the corresponding attribute of the prototype of the object, and
then affects the object instance through prototype inheritance.
jcscwf.tex; 23/11/1998; 18:36; p.16
Tailoring Groupware: The Cooperative Hypermedia Approach
17
New types of objects are created by first creating an object of a selected
prototype from the set of base prototypes and then assigning a new type name.
For instance, when a node of a new type is created using the schema editor,
the system will ask the user for its name, its category, its semantic type, and
its page type (which can be a new one or an existing one selected from a
dialog box). When a new page type is created, it will be available for users
to select in subsequent node creation processes. When a node with a new
page type is opened, a blank page with a set of default object types (i.e.,
the base prototypes defined at meta-model level) is provided. These default
object types are not included in the palette of the page. New object types can
be created from the default types with a menu operation. Whenever an object
of a new type is created, the new object type will be put into the palette.
During the creation process, some attribute values will be assigned in dialog
boxes. Other attributes will take default values and can be reset when needed.
Using the schema editor's example-based schema definition approach
end users can tailor the shared information space cooperatively to their needs.
The flexible editor: The flexible editor supports the co-existence of a wide
range of informal and formal information structures: from handwriting, drawings, text, untyped nodes and links, to typed nodes and links with or without
process-related computational semantics. The flexible editor also supports
transformation between these structures, for instance, from a text item to an
untyped node, from an untyped node to a typed node, and from a typed node
without process computational semantics to a type node with such semantics,
and vise verser.
The flexible editor takes a gradual evolutionary approach to create emergent structures. It allows users to draw from scratch with the possibility of
reusing existing activity space instances. With the tool users can create objects of default types or copy objects of existing types first, and then change
them with stepwise refinement until a desired structure appears. This makes
the tool simpler and faster with few dialogs for users to complete in each
operation. When a good pattern emerges, users can ask the system to make it
a schema. The editor can also be used to author hypermedia documents that
are free from being constrained by any schema.
The default node and link types in the flexible editor are untyped nodes
and links. Users can change the type of instances with a retype menu operation activated upon them. After objects of new types are created, their
graphical views can be seen on the current page and their types are added
into the type palette. When a new node type is created, a default page type
called `unpublished' is attached to the node type, and this page type is not
available for users to choose in subsequent node creation operations. Users
can publish a page type for others to use by assigning it a unique name. After
jcscwf.tex; 23/11/1998; 18:36; p.17
18
Weigang Wang and Jörg M. Haake
all page types in a document are published, the root page type of the document
can be used to generate new activity space instances of this document type.
Using this tool, end users can cooperatively tailor the shared information
space to emergent needs.
4.3.3. Tailoring at the instance level
The tailoring method proposed for the instance level is to modify instances
under the constraints of a given model. An activity space schema is more than
a template because many different instances can be created from a schema
(a semantic page type). Constraints and other knowledge in the schema can
provide users with context-sensitive help in creating and tailoring the instances. For this purpose, an activity space instance editor that is aimed at
end-users can be used. The attribute values assigned at this level are local to
these instances. Except for constraint-related attributes that differentiate one
type from another, many inherited attribute values assigned at the model level
(to page schema or its component prototypes) can be overwritten or changed
back to their inherited values (i.e. their default settings).
Whenever possible, constraints are turned into permissible choices in
a given context, rather than allowing illegal actions to be attempted and
then aborted. However, there are still situations when a violation can not be
foreseen before an action is taken. For instance, an acyclicity constraint can
only be checked after an organizational link (or node) creation operation is
submitted. In these situations a warning with explanations is given during
automatic abortion of the operation.
The activity space instance editor: In the session object of the activity space
instance editor, all attributes (if allowed to be changed here) are coupled with
object instances. When a node is opened in an activity space instance editor,
the editor displays the content page and a type palette with all pre-defined
object types that are permitted on the page. When a new object is to be created
with a menu selection, the allowed object types (if more than one) will be
provided in a dialog box for users to choose (if there is only one, then the
creation will be done without a dialog). A warning and explanation message
will be given when no possible choice exists. When a new object is to be
created from the type palette, an error message will also be displayed if a
structural or relational constraint is violated. The annotated example used for
defining the page schema can be accessed by pressing a help button in the
instance editor. When activated, a read-only browser presents the example
page that corresponds to the page type of the current page displayed in the
activity space instance editor.
Using the activity space instance editor, end users can tailor those properties of the shared information space that do not violate the constraints of
the model.
jcscwf.tex; 23/11/1998; 18:36; p.18
Tailoring Groupware: The Cooperative Hypermedia Approach
19
5. Tailoring in an Integrated Fashion
The cooperative hypermedia based activity space is the central abstraction of
the CHIPS system. Coordination means, role-based organizational context,
and the session-based interface linkage are properties of the cooperative activity space. The tailoring of an activity space can be done through tailoring its
component hypermedia objects or object types. The tailoring of coordination
means can be done by incorporating and combining different coordination
mechanisms (such as shared artifacts, shared interface control, role-based
access control, role-based or mediator-based coordination, and workflowlike processes) into an activity space, so as to make it a kind of process
space. Tailoring an organizational context is done via modification of the rolebased organization structure. The tailoring of interface linkage is performed
through tailoring the coupling aspects of a session type (i.e., by modifying
the coupling attribute list of the session object) or through switching between
existing session types. Above tailorings of different aspects are interrelated.
For instance, role-based access permission relates to the role-based organization structure, while the change of coupling aspects in a session will change
the coordination style supported in an activity space.
Next, we present an example application derived from the scenario introduced at the beginning of the paper to see how tailoring for cooperation
is supported in an integrated fashion. It shows how a decision making task is
performed in a multi-phase cooperative process. Remember, the sample task
is to decide which software environments to use within an organizational unit.
First, the team members of the research group create a shared information space using the flexible editor. The proposed software environments
are recorded using text objects and untyped nodes, whose contents contain
further explanations. After the brainstorming phase, they decide to use an
Issue-based schema for further discussion. Therefore, they tailor the shared
information space into an activity space with an IBIS structure. Figure 3
shows that one of the team members, Wang, transforms an untyped node into
a new Position type node.
Then, the team members decide to continue the decision-making task in
a more formal process. To initiate a process definition, first, roles taking part
in the process are defined with a user-role assignment editor (if existing roles
are not applicable to this process). In this case, the roles are `software issue
mediator' and `software issue advisor' . The first role mediates the process and
is taken by the head of the research group, Haake. The second role is taken
by all the decision-making participants in the research group. Then, with the
schema editor, a decision making process schema (named Co-decision) is
created (see Figure 4 for the final process structure), which initially includes
two subtask schemas for the two phases of the process. The first phase is a
planning phase where Issues and Positions are raised. The second phase is a
jcscwf.tex; 23/11/1998; 18:36; p.19
20
Weigang Wang and Jörg M. Haake
Figure 3. Changing an untyped node to a typed node
discussion phase where advisors would debate by enumerating pros and cons
to the positions generated in the first phase. Then, in a permission-role assignment dialog box, access permissions are assigned to roles on a per object type
basis. More specifically, Issue type nodes can be updated (created/deleted) by
a mediator. Position, Pro and Con type nodes can be updated by all advisors.
Only the mediator can authorize permissions and execute the process (i.e.,
trigger state transitions). `Any user' can query (navigate) the process, but not
change it. The first two roles are then assigned as actors of the process (and
its phases) in a role-actor assignment dialog.
After specifying the process schema, a process instance of the schema is
created using a copy-as-template operation. Attribute values, such as process
`start time' and task `duration' , whose scope is local to this process instance,
are assigned. Next, Haake starts the process by triggering the play button on
the user interface of the process space. At this point, Haake realizes that there
is something missing in the process definition: a ballot should be performed
after the discussion phase. By consulting the CHIPS system mediator, he
notices that user Wang is on-line. Thus, he invites Wang to discuss the modification of the process by adding Wang to the user list of his current editing
session. Working together they modify the process structure (the schema and
the process instance) on-the-fly. They add a Ballot phase, which is defined
as a shared whiteboard for carrying out the task with informal coordination.
Then, they add task computational semantics to the Ballot node type and turn
the regular hypertext node into a task node (see Figure 4), so that task related
attributes (such as `duration' and `actor' ) can be assigned to the node and the
jcscwf.tex; 23/11/1998; 18:36; p.20
Tailoring Groupware: The Cooperative Hypermedia Approach
21
Figure 4. Changing a hypertext node to a workflow task node
time indications of the task node, such as `duration' and `end date' , can be
seen on the view of the newly created typed node. They also add an annotation
on the root page of the process instance as an indirect communication mechanism to make the goal of the process clear. Also, an Exploration node and
an explore link are added as associated references to background information
of the primary co-decision task.
As the content of the first subtask node is completed and transformed
into an IBIS structure with the flexible editor, Haake presses the Stop button to end the task. After the task is completed, its data are passed along
`integrate' link into its following Discussion task node, and all discussion
advisors are notified by an email notification. When a team member opens
this Discussion node, he or she will work alone in a loosely-coupled cooperation mode, i.e., his or her navigation action would not affect the browsers
of cooperating users. However, if users decide to work in a tightly-coupled
cooperation mode, all users would follow the navigational actions of other
users in the same session. Similarly, after the discussion task, all the actors of
the final phase are notified to cast their ballot.
This example shows that through tailoring, CHIPS can not only support
a wide range of information structures and coordination means, but also support the co-existence of and smooth transition between these structures and
their corresponding coordination means so as to suit the work situation at
hand. To see the time-based nature of the examples better, a series of pictures
is given at our web site (http://www.darmstadt.gmd.de/concert/projects/chips.html).
Readers with a PC can access a ScreenCam movie at the CHIPS web page to
see CHIPS at work.
jcscwf.tex; 23/11/1998; 18:36; p.21
22
Weigang Wang and Jörg M. Haake
6. Conclusions
In this paper, an approach for tackling tailoring of groupware in an integrated
fashion has been presented. This approach supports the tailoring of properties
of the shared information space and of properties of group process support
by end users. An analysis of groupware tailorability led to requirements on
tailoring (1) the design of shared information spaces, (2) the coordination
means, (3) the access control provided, and (4) the user interface to the shared
workspace. Our approach uses a cooperative hypermedia based information
system framework as a unifying representation of shared information structures, functionality, and the coordination medium of a shared application.
This framework provides a tailorable foundation to support the integrated
view of tailorability on all aspects of a shared information space and group
interaction processes. In this framework, three levels of tailorability and their
supporting methods and tools are provided for different levels of users, from
programmers to ordinary users.
Systems built using our approach can support cooperative definition of
shared information structures, shared process models and their access models
not only before collaboration starts, but also on the fly, when emergent processes evolve. The proposed approach addresses tailoring at all stages of the
development and use of a groupware application.
A prototype system called CHIPS has been presented and different
possibilities of tailoring in CHIPS were discussed. The implementation and
extensibility of the CHIPS meta-models is based on the COAST objectoriented application framework, which aims at application programmers. The
example-based schema definition method and tools support ordinary end
users (non-programmers) to tailor specific models for specific tasks (or processes). The schema instance editor provides these users with intelligent aid
in tailoring various instances of the same schema. As the tools for schema
definition and instance creation are cooperative, a group can tailor properties
of their cooperative work environment (such as the shared information spaces,
group processes, and access to their content and structure) together.
Our approach goes beyond previous work in a number of ways. Compared to tailoring approaches for single user systems our approach deals with
tailoring not only behavior for individual users but also addresses tailoring
of group process support by the group itself. Compared to previous work
on hypermedia systems, our approach combines the approaches of templates
with the approach of providing schemata. However, in our approach end
users can easily define and tailor schemata, templates and instances using the
example-based definition method. Furthermore, compared to single-user hypermedia systems our approach deals with cooperative processes. Compared
to cooperative hypermedia systems our approach lets end users tailor not only
properties of the shared information space but also properties of the group
jcscwf.tex; 23/11/1998; 18:36; p.22
Tailoring Groupware: The Cooperative Hypermedia Approach
23
process support provided (e.g., by defining or tailoring coordination structures or access permissions). Previous cooperative hypermedia systems like
Aquanet, SEPIA, and KMS do not support the tailoring of process support.
Trellis, with its Petri-net based approach can in principle model information
space and processes. However, Trellis requires programming in Petri-nets and
thus does not support ordinary end users. Finally, the cooperative versioned
SEPIA system already supported the tailoring of tasks or process structures.
However, in this system only task structures composed of existing building
blocks could be tailored. New types required the work of a programmer.
As Rogers (Rogers, 1994) pointed out, users show resistance when established work practices are to be abandoned. Thus, we decided to support
emergent structure to minimize radical changes and allow smooth adaptation
of work practices. Similar to Prospero (Dourish, 1995), CHIPS also supports
a kind of computational reflection assuming that a change in structure (representation) may result in a change of function (behavior). CHIPS tries to
let users make gradual structural changes that lead to gradual changes in
function. For realizing computational reflection, Prospero uses the metaobject
protocol technique, while CHIPS employs the object prototype technique.
In CHIPS, different information spaces for different tasks (or processes) are
modeled as hypermedia based activity spaces. Users can create, modify, and
change the behavior of an activity space by manipulating the structure of its
component hypermedia objects, for instance, by adding new steps to a process
definition (at instance level), or by modifying the schema of an activity space
(at the model level, through modifying its component prototypes or changing
prototypes of its component objects). CHIPS places an emphasis on supporting hypermedia based tailoring at the model and instance levels for end-users.
Comparable to the Prospero metalevel tailoring, CHIPS also provides a kind
of metalevel tailoring for programmers. This is needed because the CHIPS
example-based prototype definition method can only create prototypes from
existing base prototypes and can only select behaviors from their classes.
New base prototypes and new behaviors have to be added into the classes
developed under the COAST framework.
As a conclusion from our work we can say that our approach meets
the requirements of tailoring groupware, as identified in this paper: First, it
supports an integrated view of tailoring information space and group process aspects. This is done via a combined representation of these aspects via
hypermedia structures. Second, using the meta-model, model and instance
levels and the example-based method for defining and tailoring information
space and coordination structures, ordinary end users should be able to tailor cooperative workspaces without a need to program. However, if more
sophisticated tailoring at meta-model level is required, developers can use
the framework to add this behavior. Third, our approach supports the entire
jcscwf.tex; 23/11/1998; 18:36; p.23
24
Weigang Wang and Jörg M. Haake
development and use cycle of groupware. This flexibility facilitates different
styles of tailoring (such as top-down, bottom-up).
Items for future work are relating to applying and testing our technology in real-world user communities. So far, we have tested CHIPS in our
group and our experiences indicate its usefulness. Further evaluation is on
our agenda. Finally, we are currently working on the inclusion of CHIPS
concepts into the COAST framework. This would help groupware developers
to implement systems providing improved tailorability.
Acknowledgements
The authors thank Daniel Tietze and the anonymous reviewers for their
detailed suggestions.
References
Akscyn, R., D. McCracken, and E. Yoder: 1988, `KMS: A Distributed Hypermedia System for
Managing Knowledge in Organizations' . Communications of the ACM, 31, 7 pp. 820–835.
Conklin, J.: 1988, `M. Begeman gIBIS: A Hypertext Tool for Exploratory Policy Discussion' .
ACM Transactions on Office Information Systems, 6, 4 pp. 303–331.
Dourish, P.: 1995, `Developing a Reflective Model of Collaborative Systems' . ACM
Transactions on Computer-Human Interaction, 2(1) pp. 40–63.
Ellis, C. A. and G. L. Rein: 1991, `Groupware - Some Issues and Experiences' . ACM Comm.
34, 1 pp. 38–58.
Furuta, R. and D. Stotts: 1994, `Interpreted Collaboration Protocols and their use in Groupware Prototyping' . In: Proc. of ACM CSCW 94. Chapel Hill, NC, USA, pp. 121–313.
Goodman, D.: 1987, `Hypercard' . MacIntosh Today pp. 60–64.
Haake, A. and J. M. Haake: 1993, `Take CoVer: Exploiting version support in cooperative
systems' . In: Proceedings of the InterCHI ' 93. Amsterdam, Netherlands, pp. 406–413.
Haake, J. M. and B. Wilson: October 31-November 4, 1992 138-146, `Supporting Collaborative Writing of Hyperdocuments in SEPIA' . In: Proceedings of CSCW' 92. Toronto,
Canada.
Halasz, F. G.: 1991, `Seven Issues: Revisited' . In: Keynotd Address in Hypertext' 91
Conference.
Knopik, T. and A. Bapat: 1994, `The Role of Node and Link Types in Open Hypermedia
Systems' . In: Proceedings of the ECHT' 94 Workshop on Open Hypermedia Systems.
Edinburgh, Scotland„ pp. 33–36.
Malone, T., K. Lai, and C. Fry: 1992, `Experiments with Oval: A Radically Tailorable Tool for
Cooperative Work' . In: Proceedings of ACM CSCW' 92. Toronto, Canada, pp. 289–297.
Marshall, C. C., F. Halasz, R. A. Rogers, and W. C. Janssen, Jr.: 1991, `Aquanet: A Hypertext
Tool to Hold Your Knowledge in Place' . In: Proceedings of ACM Hypertext' 91.
McCall, R., P. Bennett, P. D' Oronzio, J. Ostwald, F. Shipman, and N. Wallace: 1990,
`PHIDIAS: Integrating CAD Graphics into Dynamic Hypertext' . In: Proceedings of the
ECHT' 90 European Conference on Hypertext. pp. 152–165.
jcscwf.tex; 23/11/1998; 18:36; p.24
Tailoring Groupware: The Cooperative Hypermedia Approach
25
Nanard, J. and M. Nanard: 1991, `Using Structured Types to Incorporate Knowledge in
Hypertext' . In: Proceedings of ACM Hypertext' 91. pp. 329–343.
Okamura, K., M. Fujimoto, W. J. Orlikowski, and J. Yates: 1994, `Helping CSCW Applications Succeed: The Role of Mediators in the Context of Use' . In: Proceedings of ACM
CSCW' 94. pp. 55–65.
Rogers, Y.: 1994, `Exploring Obstacles: Integrating CSCW in Evolving Organizations' . In:
Proceedings of ACM CSCW' 94. pp. 67–77.
Sandhu, R. and P. Samarati: 1996, `Authentication, access control, and audit' . ACM Comput.
Surv. 28, 1, pp. 241–243.
Schuckmann, C., J. Schümmer, L. Kirchner, and J. Haake: 1996, `Designing object-oriented
synchronors groupware with COAST' . In: Proceedings of ACM CSCW' 96 Conference.
Boston, pp. 30–38.
Streitz, N., J. Haake, J. Hannemann, A. Lemke, W. Schuler, H. Schutt, and M. Thüring: 1992,
`SEPIA: A Cooperative Hypermedia Authoring Environment' . In: Proceedings of ACM
Hypertext' 92. pp. 11–22.
Trigg, R. H. and S. Bodker: 1994, `From Implementation to Design: Tailoring and the
Emergence of the Systematization in CSCW' . In: Proceedings of ACM CSCW' 94. pp.
45–54.
Trigg, R. H., T. P. Moran, and F. G. Halasz: 1987, `Adaptability and Tailorability in NoteCards' . In: Proceedings of IFIP INTERACTION' 87: Human-Computer Interaction. pp.
723–728.
Tyugu, E.: 1991, `Three New-Generation Software Environments' . Communications of the
ACM, 34, 6 pp. 46–59.
Wang, W. and J. Haake: 1997, `Supporting User-defined Activity Spaces' . In: Proceedings of
ACM Hypertext' 97. pp. 112–123.
Wang, W. and J. M. Haake: 1998, `Flexible Coordination with Cooperative Hypermedia' . In:
Proceedings of ACM Hypertext' 98. pp. 245–255.
jcscwf.tex; 23/11/1998; 18:36; p.25
jcscwf.tex; 23/11/1998; 18:36; p.26