Tailoring Groupware: The Cooperative Hypermedia Approach

Transcription

1 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, Darmstadt, Germany {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 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

3 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 A SCENARIO 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 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 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 injcscwf.tex; 23/11/1998; 18:36; p.4

5 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 WHAT 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 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 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 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 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 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 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

7 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 (Mc- Call 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 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

9 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 CHIPS IN A NUTSHELL 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 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, andnode 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 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

11 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) 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 12 Weigang Wang and Jörg M. Haake 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 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', `sesjcscwf.tex; 23/11/1998; 18:36; p.12

13 Tailoring Groupware: The Cooperative Hypermedia Approach 13 sion', `instance', and `type'. These values provide parameters for the access operations IMPLEMENTATION TECHNIQUES 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) TAILORING TECHNIQUES 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 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 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 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 protojcscwf.tex; 23/11/1998; 18:36; p.14

15 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 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

17 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 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 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

19 Tailoring Groupware: The Cooperative Hypermedia Approach 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 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

21 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 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 ( 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