XCHIPS: Towards an Integrated Cooperative Learning and

Supporting Cooperative Learning in Distributed Project Teams Weigang Wang1, Jörg M. Haake2, and Martin Wessner1 1

Fraunhofer Institute for Integrated Publication and Information Systems (IPSI) Dolivostr. 15, 64293 Darmstadt {wwang, wessner}@ipsi.fhg.de 2 FernUniversitaet Hagen, Computer Science VI Informatikzentrum, Universitaetsstr. 1 D-58084 Hagen, Germany [email protected]

Abstract. The trend towards rapid development and globalization of business activities requires business teams to carry out their projects in a distributed environment. Changes in the environment as well as in the team require these teams to continuously learn and to learn new knowledge and skills and to adapt their work processes. In such a distributed working and learning setting, team members need a shared information space to interact with various information resources and to coordinate and communicate to harmonize their actions. In our approach we combine work (i.e. the definition and execution of work processes) and learning (i.e. the learning and practicing of work processes) of distributed project teams. A cooperative visual hypermedia environment has been developed which offers support for cooperative work and learning. This visual environment provides various real-time dynamic views of the underlying work processes. These views help team members to identify situations that trigger a need for cooperative learning. By combining the work and the learning processes, this environment offers new possibilities for cooperative learning in distributed project teams such as process simulation, guided tours by experts through process descriptions and best practice examples, and cooperative roleplay for practicing work processes.

1 Introduction In today’s global economy, companies operate on a global scale. New forms of organizations, such as extended enterprises and virtual companies, are formed to meet the challenges of globalization. In these networked organizations, business processes require distributed teamwork. Due to changes of the environment, of the team, of the business processes themselves, teams must continuously learn and improve. This requires not only support for collaborative execution of business processes, but also demands support for continuous learning in the team. Since work and learning are interrelated activities, integrated support for working and learning together is needed. Current approaches to support joint execution of business processes focus on the flexible modeling and execution of business processes, e.g. by flexible, emergent workflow management systems (Haake & Wang 1999). However, these approaches R. Meersman, Z. Tari (Eds.): CoopIS/DOA/ODBASE 2002, LNCS 2519, pp. 266–285, 2002. © Springer-Verlag Berlin Heidelberg 2002

Supporting Cooperative Learning in Distributed Project Teams

267

neglect the need to support learning in the team. On the other hand, collaborative learning environments aim on supporting learning in co-located and distributed teams (Stahl 2002). However, these approaches are primarily applied in school and university settings, and they do not take into account the needs of work process execution (as is the primary goal of business activities). Consequently, current collaborative learning environments have not been applied to support work execution. Thus, the provision of an integrated working and learning environment is an open issue. Our approach to solving this problem is to provide a cooperative visual hypermedia environment. This approach combines the description of the work process (“process to be learnt and executed”) and the “learning process” (i.e. didactics) in a flexible manner. Such an environment offers new possibilities for learning in distributed teams, such as animated simulations of processes, guided tours by experts through process descriptions and best practice examples, and cooperative role-play for practicing the task. Based on its shared hypermedia workspace and process support, this environment provides support for a combination of cooperative work and cooperative learning. The rest of the paper is organized as follows: In section 2 we identify requirements to the support of teams for cooperative work and learning, followed by a discussion of related work in section 3. Section 4 presents our approach: cooperative visual hypermedia. Section 5 describes the implementation of an environment for cooperative work and learning based on the cooperative visual hypermedia approach. Section 6 presents a use case and user experience. Section 7 concludes the paper with a summary, a comparison to related work, and plans for further work.

2 Problem Analysis As sketched in the introductory section, collaborative execution of business processes lead to a high demand for joint learning in the team. We use a typical scenario from a software production company to illustrate the problems. A distributed software development team consists of several software developers and a project manager and an assistant. The team was assigned a software development project for a customer. Within a given time and budget, the team must deliver the software, the documentation etc. We can view the project plan and the assignment of tasks to team members as the business process or work process executed by the team. When new team members join, obviously a need for learning (by the new member) and adapting the process (by assigning work to the new member) arises. In the company, a separate testing unit ensures the quality of the code developed in each project. When the method employed by this testing unit changes (e.g. from code review to computer generated tests), this has an impact on all projects, which may need to deliver different data to the test unit at a different schedule. Thus, a need for learning about the change and its consequences as well as necessary adaptations of the project plan arises. While doing their work, a team member might recognize a problem in the current project plan (e.g. a certain procedure cannot be applied in this case, which invalidates the whole plan). The team must now be notified about the problem. After some joint discussion, a solution is found and must

268

W. Wang, J.M. Haake, and M. Wessner

be reflected in a change of the project plan and its implementation (i.e. the work process structure of the team). These changes need to be communicated, learned, tested and practiced, before the work can continue. When the solution to the problem requires adopting a completely new process (e.g. a switch from the traditional software development methodology to a new one, such a extreme programming, or a new documentation policy required by the customer or the law), the team must jointly understand and practice the new process, before they can work effectively. Learning in the team is primarily triggered by the following two types of causes: (1) External causes (caused from the environment): - Changing team members: new team members need to understand the way the team works, e.g. the goals and objectives, the work processes and their decomposition and dependencies, the allocation of tasks to people, the way the team coordinates and communicates; - Changing work processes: business processes usually depend on other business processes. If some of the “external” business processes change (e.g. the buying process of a company is changed), the “internal” business process (e.g. those business processes using the buying process, such as a production process needing to buy parts) is affected and needs to be adapted. In this case, the team needs to learn about the external changes and to develop (and learn) a new way of doing their work; (2) Internal causes (caused/triggered within the team): - Problems during work process execution due to inadequate processes: here, a team member might detect a problem with a task within the work process (e.g. that process is not applicable to the case at hand). In this situation, the team members who are working on dependent tasks need to jointly adapt their work process to solve the problem. The new work process, if sufficiently new and different from prior work practice, may need to be practiced and tested; - Problems during work process execution due to unknown/new processes: here, the team members need to jointly understand and practice the new work process, before it can be successfully executed. As a consequence of the above problem analysis, we can identify the following requirements for learning support addressing the needs of collaborative execution of business processes in distributed teams:

-

-

Joint execution support is the basis for the team work: o Representing, sharing and joint execution of work processes o Coordination of work distribution and work performance o Coordination of access to shared documents used in different sub tasks Individual learning support: o Understand work process structure (goals, objectives, work decomposition, dependencies) o Find examples of process execution (best practice)


-

-

-

269

Support for external process changes o Signal changes to members working on dependent tasks o Explain changes o Provide training for changed processes o Support adaptation of current tasks Support for joint modification of work processes o Support discussion of detected problems o Support joint adaptation of work processes o Support documentation of the changes Support joint learning and training o Support for jointly explore and understand a new process o Support for practicing a new process in the team Support for joint evaluation and improvement of the team’s performance

3 Related Work Related work can be primarily found in three areas: workflow management, shared workspace systems, and collaborative learning environments. Workflow systems focus on automated process support. Usually, a workflow system supports the definition and coordinated execution of work processes, including the provision of access to information resources needed in specific tasks (Graether et al 1997). Learning about processes is usually not explicitly supported. Some workflow systems support modifications of running work processes. These ad hoc or emergent workflow systems provide more flexibility with respect to exception handling (Haake & Wang 1999). However, they do not support learning about process changes and training of redefined processes. Workflow systems in general focus on a separation of individual definition and execution phases. Thus, joint discussion of problems and joint construction or adaptation of processes are not supported. Likewise, there is no support for joint learning and training of work processes. Finally, workflow systems are good in collecting performance data. However, they neglect joint evaluation and improvement of a team’s performance. Whereas shared document systems, such as BSCW (Bentley et al 1995) enable shared viewing or shared editing of isolated documents, this work tries to exploit CSCW and hypermedia technology to facilitate rich information structures and seamless process support through the provision of shared workspaces. Collaborative learning environments support the joint construction and acquisition of knowledge. Often, this includes also support for individual learning as a prerequisite for or as a component of collaborative learning. Process support is offered by some systems as support for specific learning methods, e.g. following the concept of scripted cooperation (Wessner et al. 1999). Work processes as the subject of learning are usually not explicitly supported. Some collaborative learning systems support role-play, which can be used to practice work processes in the team. Often performance data is logged and used by collaborative learning systems in order to provide information on the participation and its distribution in a team. Some systems support one or a limited set of (well structured) learning situations where conflicts in the learning process can be detected automatically (Mühlenbrock & Hoppe 1999).

270


While workflow systems support the definition and coordinated execution of work processes and collaborative learning systems support the joint construction and acquisition of knowledge, there is no system which fulfills the requirements for learning support addressing the needs of collaborative execution of distributed business processes as identified above.

4 The Cooperative Visual Hypermedia Approach In the following subsections, we first outline the cooperative visual hypermedia approach to integrating cooperative learning support into cooperative work settings. Then, the concept cooperative visual hypermedia is presented and related to other hypertext domains. After that, the approach is detailed with respect to the support for work processes and the support for change management. The implementation of an environment based on this approach will be provided in section 5. 4.1 The Approach in a Nutshell Our approach is based on cooperative visual hypermedia technology, which provides a shared hypermedia information space with the following key features: An extensible set of visual hypermedia object types that can represent not only shared information objects and structures (e.g. the content to work on or to learn from) but also cooperative processes (i.e. the working or learning processes). These include object types representing o Content structures (i.e., information resources) composed of object types such as graphical and textual types for sketching ideas (e.g., scribble and text), types for presenting a domain-specific hypertext structure, and types for referring to external documents. o Process structures composed of object types such as types for presenting tasks, nested composite tasks, and types for representing dependency relationships. o Team structures (i.e., organization structures) composed of object types such as types for team, role, and person, types representing the relationships within team structures, and o Types for relationships across content, team, and process structures. Flexible process support o For process enactment, which allows both automatic process execution and interactive execution (especially when a problem arises). o For cooperative process modeling and for the joint modification of a running process and its resources. o For cooperative process animation (animated simulation) and role-play. Change management support for identifying and handling changes caused by both internal and external reasons. This is supported by using three kinds of dynamic views on the same hypermedia model in the shared workspace: o A tree view which provides an overview across multiple process structures run by different projects and teams, o A nested view which provides a detailed local view at each level of a process structure, and


o

271

A swim lane view that provides a filtered flat view of a running process with ordered tasks in individual lanes for each respective team member.

Other features, which are not discussed in detail due to space reasons, include the session management, the integration of communication and cooperation tools, document handling, and the integration with the Web: o Session management enables the users to meet in a virtual place (in the shared information space). o Cooperative visual hypermedia environments foster communication and cooperation also by the integration of textual and audio/video communication, application sharing, and document handling capabilities. o Document handling capabilities allow external documents be linked into the process structure for accessing, manipulating, and managing them in a process context. o The tight integration with the Web enables wide accessibility of the environment, reuse of existing documents, dealing with firewall problems etc. 4.2 Cooperative Visual Hypermedia The cooperative visual hypermedia presented in this paper combines features found in the several hypertext domains and in many object-oriented drawing systems. Hypertext and hypertext domains. The classical hypertext is a graph-based navigational hypertext, which distinguishes information components (nodes) and relationships (links) between these components (Halasz & Schwartz 1994). Using links, linear as well as nonlinear network structures can be formed. In addition to the basic notion of nodes and links, one can introduce types of nodes and types of links. These types can be used to capture application or domain semantics, e.g., by determining allowed types of nodes as link end points of specific types of links. In addition to simple nodes, many hypertext systems introduced composite nodes (composites) that can contain other nodes and links. Composite nodes can be used to form aggregated subnets within a hyperdocument, which lead to the possibility of layered graphs or networks. Navigational hypertext is normally presented to users as a content page with highlight embedded links (e.g. a Web page). Navigational hypertext structures may also be presented visually as hypertext maps, in which labeled square or icons represented nodes and arrow lines between them represent links. In addition to navigational hypertext, there are also several other hypertext flavors (or domains), such as set-based taxonomy hypertext (Parnuak & Van Dyke 1991), layout-based spatial hypertext (Marshal & Shipman III 1997), and automatonbased workflow hypertext (Furuta & Stotts 1994): - Set-based hypertext uses containment relationship exclusively, e.g. to represent taxonomy hierarchies. Set-based hypertext is presented as unfoldable indented hierarchies or nested graphical areas. - Spatial hypertext uses spatial layout and some visual characteristics to represent relationship. For instances, similar information objects are placed near to each other.

272


-

Workflow hypertext is hypertext with application domain specific computational semantics, for instance, browsing semantics or control flow and data flow semantics along links. Two other extensions of the hypertext concept are hypermedia and collaborative hypermedia: Hypermedia allows text as well as any kind of multimedia information to be the content of a node. Collaborative hypermedia or groupware hypermedia adds to the hypermedia concept the possibility of sharing a hypermedia workspace among many people. Visual hypermedia. Visual hypermedia combines various features found in the above-mentioned hypertext domains and in many object-oriented drawing systems. In addition to explicit links, such a system can make use of various visual properties found in drawing systems for the expressing relationship among various visual artifacts. These visual properties include the (foreground and background) colors, patterns, images, the label text, the size, the orientation, the position, the shape, and the Z-ordering of the visual components. For instance, similar things may be placed near to each other and visualized in similar color or image patterns. What differs from a drawing system is that all these visual components are hypermedia objects that can be re-organized into different sets or nested structures, be linked to or referred to each other, and linked to external documents.

Fig. 1. Visual hypermedia: a mixture of multiple hypertext flavors

Figure 1 shows an example of the visual content captured in a learning session on market analysis. In this example, the graphical representations of spatial and navigational hypermedia co-exist in the content pane. A list of pie chart images are placed together representing Market Segments. The Business Partner (as an image of shaking hands) and the Business Competitor (as an image of wrestling hands) are placed near to each other and both of them use a similar background image pattern. Explicit links (represented as arrow lines) are used to indicate that some of the market


273

segments are in the scope of the business partners and that others are in the scope of the business competitors. Here the navigational (semantic network map) metaphor is used together with the spatial and visual metaphors to enrich the expressiveness of a visual hypermedia. Visual hypermedia can be used to represent the content of a cooperation, the cooperating team, and the cooperation process itself. Moving from individual to cooperative visual hypermedia and based on the workflow hypertext functionality, these processes can also be defined and executed jointly. 4.3 Flexible Process Support A process structure can be described as a directed graph consisting of a coordination structure among the steps. Such a graph can be modeled as a typed hypermedia structure (see also (Haake & Wang 1999)). In our approach, the process structure is represented by a set of pre-defined hypermedia object types: Task nodes, which may carry a description of the task and other information objects (such as embedded links to external documents) as its contents, and which can be related to other resources via specific explicit links, such as a “assign” link from a role (or position). When a task node contains other task nodes connected with process links, it becomes a composite task node that presents a process or a sub process. Thus, processes can be nested and may form a layered graph. This nesting allows for representing the decomposition of work procedures into smaller parts. Task nodes have process-specific attributes, such as state, scheduled starting time, and duration. They have also process-specific behaviors, such as state transitions and activation of certain actions, Process links, which represent precedence relationship between task nodes. Process links have control flow and data flow behaviors. For example, instances of the process link type “precede" can be used to link tasks and processes into sequences or parallel structures, where each precede link specifies under which condition the successor node can be activated and which documents will then flow from the predecessor node to the successor node, Role (or position) nodes, which specify the responsibility in a process or an organization, Assignment links, which assign a role to a task. Person nodes, placeholders that present actual individuals, Filled-by links, which specify which Roles are assumed by which Persons, and Any other nodes or links for additional information, such as information about the goals and objectives of the work process, background information, and resources. Thus, in such a typed hypermedia environment, a process can be represented as graphs consisting of typed hypermedia objects, together with additional information related to the process. For a clear overview of the state of a process, the state information of task nodes is color-coded in their views (white for inactive, yellow for enabled, green for active and brown for completed). Tasks can be performed by menu operations activated on the task nodes. Selecting "enable" and then "activate" menu operations on the root composite task node of a process structure can start the process execution. When a composite task node is "activated", the starting tasks of the process structure nested in

274


the composite task node are "enabled". The "enabled" tasks can then be "activated" automatically (if they are automatic tasks) or manually (if they are manual tasks). When the work of a task is finished, its actor can select the "complete" menu operation on the task node (if the task is an automatic task, the "complete" operation will be automatically triggered when the action defined in the automatic task is finished). When all the predecessors of a task are completed, the task is "enabled". A process is completed when all its subtasks are completed. As a process structure in our approach is represented by shared hypermedia objects, it can be created or modified asynchronously or synchronously in a joint cooperative session by team members (see following sections). Our approach also allows the modification of a running process. This is made possible by visualizing monitoring the same process structure as both a process definition and as a running instance when execution starts. The execution of a process can be started by the person manages the process and the enactment of individual tasks can be done by the team members who are assigned to the tasks according to the roles they are taking. The cooperative process animation (animated simulation) and role-play is supported by cloning and enacting the process clone or by running a process in a testing mode (for either testing or learning purposes). 4.4 Change Management Support In order to deal with changes in the work process caused by internal and external reasons the hypermedia model can be presented in a number of dynamically generated views. Here, three cooperative visual hypermedia views are defined for change management: the tree view, the nested view, and the flat view of the underlying hypermedia models. Tree view for an overview. A tree view provides an overview of the task (process) break down structure of a single process or multiple processes. It also shows all the resources related to the tasks. A browser for this view is a hierarchical structure navigator, which can fold and unfold a hierarchy to show all the sub tasks and all the resources (such as roles, persons, and information objects) associated with the sub tasks (See Figure 2). The tree view may help team members to go up and down a process hierarchy of a single process or a set of processes, so as to identify a task in an overall context and find all the sub tasks and all the resources relating to the task. With such a clear view about a task, when there is anything wrong with it and needs a change, team members could easily see the scope of its impact and learn changed process structure. Nested view for local details. A nested view presents the details at each level of the task break down structure (i.e. sub process structures). A co-operative hypermedia model browser for this view allows team members to navigate in the nested structure and to create and modify a project plan (i.e., a process structure and its related resources) co-operatively. A browser for this view (see Figure 3) provides functionality of an object-oriented drawing tool: Pre-defined visual hypermedia object types can be placed in the hypermedia workspace. These object types include object types for process modeling and object types for creating information objects. There are also a general node type and a general link type that can be used to derive new


275

Fig. 2. Tree view browser

node and link types. The appearance of a new node type can be defined by modifying a newly created general node, for instance, to change its foreground and background colors or patterns, the label text, the size, the orientation, the shape, or to load an image (if it is node). Any visual object in the content pane can be used as a prototype for creating new instances of the same type. The whole nested structure of a composite node can be cloned in one operation.

Flat swim lane view. The swim lane view is a flat view: all tasks are presented on the same surface no matter which nesting levels they are. A swim lane view presents multiple ordered task list in lanes for each task performer (See Figure 4). Filtering criteria is supported to generate many kinds of task lists, such as to-do lists and overdue lists. This view supports dynamic task planning and resource assignment at any time, especially for last minute or just-past-execution changes. They are also used as a work list handler for task execution and as a task control panel for monitoring the task execution. Colors are used to show the state of a task: The red outline indicates overdue tasks. The blue outline indicates delayed tasks. The white background color is for not ready tasks. The green background color is for ongoing tasks and the yellow is for to do tasks. A variety of filtering and ordering criteria can be used to tailor the view. Unlike a to-do list in most workflow systems, such swim lane view allows team members to get an overview of various task lists of all the team members. With such a browser, team members can identify delays, actor backlogs, and bottleneck tasks that require changes of re-scheduling, resource re-assignment, and process structure modification.

276


Fig. 3. The nested view browser

4.5 Cooperative Sessions Distributed cooperative work and learning usually happen in a series of distributed meetings. A meeting is normally organized into one or more sessions. A session is also a meeting, which may involve all or part of meeting participants. In the following, we do not differentiate between meeting and session. In our approach, a session is made up of a collection of people, groupware components, and shared objects. To provide a sense of virtual place, each session is visualized as a separated session window. Each window lists the names of the on-line participants of the meeting (see Figure 2). Groupware tools used in the session will be opened in the session window. All participants of a session have a synchronous instance of the session window. Working with one browser on a view in a session, other groupware components invoked from the browser user interface or from the shared objects in its content pane can be activated. Other components can be opened either in the same session window (thus becoming accessible to all users within this session) or in a new session window (providing a simple transition to individual work or a subgroup meeting in a new session). Meeting organizers can invite other users to join their working session. Users can also use a query tool to search for all the active meeting sessions and request to join selected sessions. Communication and cooperation in the session is supported by the integration of a chat, audio/video communication, and application sharing for all on-line participants in the session.


277

Fig. 4. Swim lane browser

5 Implementation Techniques The cooperative visual hypermedia approach to support collaborative learning in distributed project teams presented in the last section has been implemented in the XCHIPS system. Throughout the preceding section screenshots form XCHIPS have been used to illustrate the approach. XCHIPS stands for eXtensible Cooperative Hypermedia Integrated with Process Support. It is a Java-based follow-up system of the Smalltalk-based CHIPS system (Haake & Wang 1999). Its process enactment support, role-based access control, and example based schema definition techniques have been published in (Haake & Wang 1999, Wang 1999, Wang & Haake 2000). For space reasons we focus on two key technologies in this section: the Java and DyCE (Tietze & Steinmetz 2000) based cooperative hypermedia system architecture and the tight integration of XCHIPS with the web. DyCE is a Java-based Dynamic Cooperation Environment. It provides dynamically replicated-shared data as well as transactional support for access to and modification of this shared data. In addition, it supports dynamic extension of the working environment by enabling users to add new mobile UI components at runtime. 5.1 System Architecture XCHIPS adopts a Web-based system architecture (See Figure 5). It Web server includes services for shared object management, groupware component management, and some infrastructure services (such as those for naming and locking). The shared

278


object management service provides dynamically replicated-shared data as well as transactional support for access to and modification of this shared data, so as to ensure the persistency and consistency of the shared data. The groupware component management service and the Web server support the dynamic addition and removal of groupware components and their dynamic download at the client side. The communication between clients and server uses an http tunneling service to replace the direct TCP/IP and RMI based communication. The cooperative hypermedia model is built on the common shared object model, therefore it has all the capability of the dynamic replication and transaction support.

Fig. 5. System Architecture

In the DyCE framework, a groupware component consists of a shared data object and mobile UI component. The mobile UI component defines the view and controller (i.e., the user interface) of the shared data object. The mobile UI model provides a framework for creating new mobile UI components. The framework supports eventbased notification for dynamic UI update when any interested aspects of the shared data changes. The XCHIPS browser is also a mobile UI component. Its shared data model is a composite object that may contain other hypermedia objects to be visualized in the browser. The relationship between a shared object type and a mobile UI component class is defined by a UIClass-service-dataClass triple declared in the mobile UI class. One data object may have more than one UI component. Their binding is decided at run time. When a user opens a node in the XCHIPS browsers, all the triple UIClass-service-dataClass objects will be searched to find the candidate UI components (classes) that may work on the shared data object (which may be the node itself or referred by the node). In XCHIPS, session and user objects are also managed as shared objects. 5.2 Integration with the Web Based on the Web-based architecture, XCHIPS is integrated with the web in order to re-use, import and export documents and in order to ease the accessibility and


279

execution of the system. The tight Web integration is implemented in the following ways: Integrated document handling into the shared visual hypermedia space. In order to integrate documents on the web into the shared visual hypermedia space and the process structures, two types of nodes are defined: The href node refers to a Web address (a URL). When it is opened, its corresponding information resource will be presented in the Web browser (or in a plug-in application). The node can also be opened for all participants in a session by using the open for all menu operation. The Webdoc node refers to a URL. When it is opened, the URL resource is locked, downloaded, and opened in a corresponding application, e.g. a Word document in MS Word. As a kind of group awareness information, the user name will appear on the node view. After editing, the document can be upload (back) to the document repository and unlocked. The href and Webdoc node types are implemented using a Java-COM bridge. Implemented XML import and export utilities based on a common type definition DTD developed in the EXTERNAL project [EXTERNAL paper], so as to allow the system to work on models created by other systems (e.g., in a joint review meeting). Using Java Web Start technique to deploy, update, and launch the system from a Web portal. As Java Web Start can automatically update a deployed system before launch it, it greatly simplifies the deployment and upgrade process. Using http tunneling to replace direct TCP/IP and RMI communication between XCHIPS server and clients, so as to solve the firewall problems. Implemented an http-based API, so that the shared hypermedia objects (i.e., the distributed object ids) can be embedded in Web pages for invoking XCHIPS on specific objects. These objects can be root objects of meeting processes or business processes a team is working on. In this way, XCHIPS (and its visual hypermedia) can be accessed through standard Web browsers. Further more, by using pre-defined (visual) hypermedia types, the document handling and process support can be extended to a wide range of information resources on the Web. By doing so, the collaborative hypermedia-based process support can be tightly integrated with Web-based information resources to extend the scope of the shared hypermedia workspace beyond what is available in XCHIPS itself. Using such extensions, background material for process learning or reference material for the context of the shared hypermedia workspace can be included in the collaborative process, the jointly created shared workspace contents can serve as meta-structure for HTML or XML pages.

6 Use Cases and User Experience In this section, we present a typical use case scenario and show how our approach is used to support it. Then we summarize our initial user experience.

280


6.1 A Typical User Scenario In section 2 we introduced a typical scenario from a software production company to illustrate the need for and problems of cooperative learning during teamwork. In the following, we show how our approach was used to support such a scenario by real users. Our usage experience comes from the EXTERNAL IST-1999-10091 project funded by the European Union. EXTERNAL develops an infrastructure, tools and a methodology for supporting the formation and operation of extended enterprises. Within the EXTERNAL project, our approach is currently used to support cooperative project planning and cooperative work execution. The EXTERNAL team consists of members from five companies located in three countries. Work has been split into 9 work packages each lead by a work package manager and staffed by members from several companies. A project manager coordinates the overall project, i.e. the proper execution of the overall project plan and the continuous adaptation of the project plan. The project plan can be interpreted as the core business process, which the team is performing. It is, of course, tightly interwoven with the business processes of the partner companies. We will now have a closer look how our approach addresses the cooperative learning needs in EXTERNAL: Changing team members: During the 2.5 years of EXTERNAL, there has been some constant change of team members, ranging from developers to work package managers to even the project manager. New team members need to understand the way the team works, e.g. the goals and objectives, the work processes and their decomposition and dependencies, the allocation of tasks to people, the way the team coordinates and communicates. This is supported by the shared hypermedia workspace to provide access to all critical information resources through a single portal (see figure 3): the goals and objectives, the organizational structures (people and their roles) as well as the project plan and all information objects used/produced in the different tasks. When a new member joins the project, she is registered in the system and given access to all information. After reading the overall goals and objectives, she looks up all the task assigned to her. In the XCHIPS Tree View browser (see figure 2), she can explore her current tasks and check how they are related to other tasks. In order to understand how this task contributes to the overall project, she checks how it developed in the past and how its results will be used in the future. She quickly finds out who else is working on related tasks by looking at the staffing of dependent tasks and by looking at people working on documents shared by several tasks. Since the project plan is a live document, i.e. it is used to perform the project work and reflects its current status, she can quickly learn how formal communication and coordination works in the project. In addition, her predecessor kept annotations in the work plan, which indicate when, why and with what results he (informally) communicated with other colleagues. So far, our approach supported some individual learning of the new team member. The system enables to discuss questions or work plans with colleagues (a form of collaborative learning). In addition, this approach helps newcomers to gain access to information, which would have not been so easy in the distributed setting of the EXTERNAL project. Changing work processes: In EXTERNAL, many interdependencies exist between work packages. Results from one work package are needed in another. If one work


281

package is delayed, this may have consequences for others. Often, problems appear in one work package, which lead to changes in that work package. If those changes influence the results needed by others (e.g. the functional specification of a software module is changed due to implementation or resource problems) we must resolve these inconsistencies as early as possible. In EXTERNAL, the execution status of tasks are marked by color-coding of the task nodes in the shared workplan (see the swim-lane view in Figure 4). When a task is changed, it is easy to compute and show (in a tree view) all other tasks potentially affected by the change (e.g. all tasks which import a software module or document, or tasks which now have to wait for a delayed task). Likewise, when the work plan of a task is changed, all dependent tasks (e.g. those sharing the same resources, results, or a timing dependency) can be shown and then manually checked for any inconsistencies. For this purpose, a separate joint project planning work process was established in EXTERNAL (see figure 2). It guides how work package and project managers perform the periodic progress reporting and planning, and supports the detection and correction of inconsistent work plans. Furthermore, notifications can be sent by the system to people involved in tasks affected by potential inconsistencies or by changed task descriptions. These people can then use the system to look at the changes and to learn about how their work should be adapted. Problems during work process execution due to inadequate processes: In EXTERNAL, team members frequently detect problems with various tasks within the work process (e.g. a certain approach does not work as planned). In this situation, the team members who are working on dependent tasks need to jointly adapt their work process so as to solve the problem. This is supported by allowing all members to jointly browse the problematic parts of the project plan and to discuss the required changes. This can be done asynchronously (via annotations and mail) or synchronuously (in a virtual meeting where people use chat and audio conference facilities together with joint editing of the shared workspace). Here, the visual hypermedia approach shows one of its strenghts: people can scribble, draw and annotate the work plan and gradually shift towards a more formal solution (i.e. the new workplan). Communication and construction of the solution is performed in the same medium. Our experience indicates that for small groups of affected team members (e.g. three workpackage managers solving a conflict, or four developers resolving an integration problem) this approach works well. As a benefit of the more formal work plan in the shared hypermedia workspace, team members affected by these changes can be notified and can use the system to learn about the changes. If needed, they can also practice the new work process (see below). Problems during work process execution due to unknown/new processes: As mentioned above, team members may need to jointly understand and practice new work processes, before they can be successfully executed. Examples in EXTERNAL include the introduction of a new project reporting and planning policy. This new procedure was described in the system as a new task with a complex, nested work plan consisting of approximately 45 (small) sub tasks. The 9 workpackage managers and the project manager used the system to first individually explore the new task and then they met in a synchronous virtual meeting where all participants jointly browsed and discuss the new proposed work process. They used the animated simulation feature to see and discuss how the process would work, and resolved several potential

282


problems by adapting the proposed work process to their needs. Eventually, the new work process for joint reporting and planning was accepted and then execution started in the environment. Though execution was largely done asynchronously, some synchronous virtual meetings happened in the shared hypermedia workspace. These were either pre-planned coordination and conflict resolution meetings, or spontaneous meetings between workpackage managers who detected mutual conflicts between their work plans. After all, participants liked the support for exploring and practicing new work processes together, and they emphasized the usefulness of learning team processes together. 6.2 User Experience So far, we have used three versions of our system in the EXTERNAL project for the last 9 months. Initial evaluation results indicate that the visual cooperative hypermedia approach supported can meet many challenges of supporting integrated cooperative working and learning:

•

•

• •

•

The visual hypermedia models capture a rich set of relationships between the organizations, people, processes and resources of the virtual enterprise. Through analysis and activation, the models become applied as sources of knowledge, providing the basis for knowledge exchange and learning. Different forms of learning (individual and collaborative, ranging from joint exploration to discussions to group simulation and practicing) can successfully be supported. For small groups (2-8 people), synchronous discussions and joint browsing/editing facilitate collaborative learning. For larger groups, asynchronous exploration, annotation and discussion were regarded more helpful. Planning, the joint construction of the current work plan by the participants is well supported. Communication is supported through the visual expressiveness of the shared hypermedia workspace, the infrastructure, and the terminology of the modeling language used for describing the shared work plan. The joint modeling of the workplan facilitates common understanding, and the extensibility of the modeling language enables local shared understanding to be expressed and utilized. Flexibility is ensured through interactive model interpretation, combining the capabilities of the system to automate predefined parts of the work processes and the users to handle incompletely specified parts of the work plan.

Users liked the color-coding of the task nodes and various content types accessible from the task node. As this allows them to see (particularly for the late comers of a meeting) what has been performed, what is on-going, and what are the next tasks. A major benefit of a persistent shared hypermedia workspace was also seen in the capture of discussion results. When used for virtual conflict resolution meetings, other team members who are not able to attend the meeting can navigate the meeting process structure (i.e. the content of the meeting task object) to learn what happened in the meeting and to find and understand the decisions made in its original meeting


283

context. Users also liked the ability to write, scribble, post visual artifacts, and to reorganize them for on-line discussions. The handling of MS documents and its integration into a process structure were considered a useful and practical solution, as all the user organizations of the use case partners of the project have MS Office suite and Windows operating system used in their daily working environment.

7 Conclusions and Future Work Computer support for cooperative work and for cooperative learning are both hot research topics. Cooperative work and cooperative learning also happen more and more often in project teams. However, these have been separated areas in both research and practice. Learning systems in most cases cannot handle real working situations; while working systems have rarely addressed the needs for cooperative learning. In this paper, we described an approach that supports cooperative learning in distributed project teams by providing a shared hypermedia information space with

A rich set of visual hypermedia objects that people can use to sketch ideas in group discussion and that can represent not only learning materials (i.e. the content to work on and to learn from) but also working and learning processes (i.e. the coordination and learning strategies), Flexible process support for process modeling, process execution, process animation, and process adaptation. Three kind of related dynamic views of a process centric project model. With the flexible process support and visual hypermedia browsers for these views, changes caused by both internal and external reasons can be handled. Session management for team members to meet in a virtual place and use a set of cooperative tools for jointing editing and navigation, Integrated support for textual and audio/video communication, application sharing, and document handling, Integration with the Web for wide accessibility.

In this approach, the cooperation environment is used as a medium for cooperative work and learning. Such a cooperative environment offers new possibilities for learning in distributed teams, such as animated simulations of processes, guided tours by experts through process descriptions and best practice examples, and cooperative role-play for practicing the task. Furthermore, this approach combines the description of the “learning process” (i.e. didactics) and the “process to be learnt” (i.e. the content of learning) in a flexible manner. Based on the shared hypermedia workspace and the process support, this approach provides support for a combination of work and learning. Here, learning smoothly turns into working (e.g. by adapting process structures to the task at hand) and vice versa (e.g. when a problem occurs during process execution and the team has to learn how to fix it, and to document it for future learners). As a sample implementation of our approach, we described the XCHIPS system, which provides cooperative visual hypermedia-based process definition and enactment support for modeling, disseminating, and evolving process knowledge. A

284


use case showed how it can be used for supporting cooperative learning needs arising in working situations. In this work, we extended our component-based cooperative hypermedia system XCHIPS [7, 22, 23] with visual hypertext artifacts, their higherlevel dynamic views, and synchronous session support for virtual learning teams. The XCHIPS system is one of the tools we developed in the EXTERNAL project (IST1999-10091) funded by the CEC. EXTERNAL focuses on the engineering and operation of networked organizations, and the management and learning of process knowledge. Next, we will broaden and apply our approach to process knowledge management, and evaluate this approach in three real-world use cases.

Acknowledgments. Thanks due to all the team members of the EXTERNAL project partners for their cooperation and feedback.

References (Bentley et al 1995) Bentley, R., Horstmann, T., Sikkel, K., and Trevor J. Supporting Collaborative Information Sharing with the World Wide Web: The BSCW Shared Workspace System. Proc. of the 4th Int. WWW Conference, Issue 1, O’Reilly, Dec. 1995, pp. 63-74. (Desanctis et al 2001) Desanctis, G, Wright, M and Jiang, Lu, Building a global learning community. Comm. of the ACM, vol. 44, December 2001, pp. 80-82. (Furuta & Stotts 1994) R. Furuta, and D. Stotts, Interpreted collaboration protocols and their use in groupware prototyping. Proc. of ACM CSCW’94, pp. 121-313. (Graether et al 1997) Wolfgang Graether, Wolfgang Prinz and Sabine Kolvenbach Gräther, Enhancing Workflows by Web Technology. Proc. of ACM Group’97, pp. 271-280. (Haake & Wang 1999) Joerg Haake and Weigang Wang (1999) Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support. Information and Software Technology (41) 6, 1999, pp. 355-366. (Halasz & Schwartz 1994) Halasz, F., and Schwartz, M. The Dexter hypertext reference model. K. Grønbæk and R. Trigg, (Eds.) Comm. of the ACM 37, 2, 1994, pp. 30-39. (Marshal & Shipman III 1997) Marshal, Catherine C and Shipman III, Frank M.: Spatial Hypertext and the Practice of Information Triage. Proc. of ACM Hypertext’97, pp. 124-133. (Mühlenbrock & Hoppe 1999) M. Muehlenbrock & H.U. Hoppe (1999). Computer supported interaction analysis of group problem solving. In J. Roschelle & C. Hoadley (Eds), Proc. of the Conference on Computer Supported Collaborative Learning CSCL-99, 1999, pp. 398-405. (Parnuak & Van Dyke 1991) Parunak, H. Van Dyke: Don't Link Me In: Set Based Hypermedia for Taxonomic Reasoning. Proc. of ACM Hypertext’91, pp.233-242. (Stahl 2002) G. Stahl (Ed.). Computer Support for Collaborative Learning. Foundations for a CSCL Community. Proc. of CSCL 2002, January 7-11, 2002, Boulder, CO, USA. Lawrence Erlbaum: Hillsdale NJ, USA. (Tietze & Steinmetz 2000) Daniel A. Tietze, Ralf Steinmetz Ein Framework zur Entwicklung komponentenbasierter Groupware. Proc. D-CSCW 2000, pp 49-62. (Wang & Haake 2000) Weigang Wang and Joerg M. Haake (2000) Tailoring Groupware: The Cooperative Hypermedia Approach. Special Issue on Tailorable Systems and Cooperative Work, Computer Supported Cooperative Work: The Journal of Collaborative Computing, Kluwer, 9(1), pp. 123-146.


285

(Wang 1999) Weigang Wang, Team-and-Role-based Organizational Context and Access Control for Cooperative Hypermedia Environments, Proc. of ACM Hypertext’99, pp 37-46. (Wessner et al. 1999) M. Wessner, H. Pfister, Y. Miao, Using Learning Protocols to Structure Computer-Supported Cooperative Learning. Proc. of the ED-MEDIA 1999, pp. 471-476.