1 Introduction

Change Laboratory (CL) is an intervention method for systematically developing work practices. It is based on the framework of developmental work research (DWR). DWR is based on 3 basic theoretical and methodological ideas:

  1. In DWR the unit of analysis is collective activity system where the common activity has a specific object. Further, the activity is defined by its components: tools, community, rules and division of labor. Singular actions and situations, such as failures, disturbances and innovations, are analysed always in relation to the whole activity system.

    Activity system is often presented using the following model:
  1. Problems in activity designate contradictories between the components of activity system. These contradictions can be made visible by analysing deviations from the normal trajectory of work. These are disturbances, breakdowns or new ideas related to the way of working. Contradictions are analysed both retrospectively, taking into account the historical development and in the present activity. Qualitative changes in the activity are effect of solving contradictories in the activity system and the new tools and ways of working that are produced in the process.
  2. In DWR change and development is examined as long-term collective learning processes. They often lead to the construction of completely new collective tools and ways of working, not just individual mental change. This kind of learning is called expansive learning.

In a typical project the participants are involved in analysis of their collective activity. This will motivate them to develop and test new solutions for the problems they face in their everyday work. By inspecting and analysing concrete material from the historical development of work (like memoir, interviews, annual reports and old documents) and present work (such as videotaped events, discussions and interviews or simulated work situations) participants construct a "mirror" of their own activity. A generalisation of activity system and its components is made by analysing the specific information acquired through this "mirror".

The history of an activity system can be percieved according to the third principle (see above) as consecutive cycles in reorganization and learning of activity system. The analysis of historical and present activity leads the working community to the step of the future, that is, to form it’s own development potential.

1.1 Setting of Change Laboratory

Developmental work research is a reflective method. This reflectivity is actualized by forming a “mirror” in front of the participants by presenting concrete material about their work. The “mirror” is used by the participants for analysing and evaluating their way of working. Simultaneously an assumption of the developmental phases and contradictions of the work is formed by a historical analysis of the work.

To help the participants consider relevant aspects during the analysis so called intermediate analysis tools are needed. This kind of tools can be different categories, classifications, four-fields etc.

Figure: General Setting of Developmental Work Research

Reflectivity also means that the moderator of the process get feedback from their own decisions and analyse their own working. A moderator may analyse her own actions for example from the videotapes of Change Laboratory sessions.

Cyclic model of expansive learning (see below) is used for phasing the Change Laboratory process. The role of the moderator is to help the participants to “push” the development of their work forward in the expansive cycle. This is achieved through different interventions. The moderator can:

  • collect and select concrete empirical material to be analysed by participants about disturbances and new solutions in their work
  • set tasks for the participants to analyse the work and to construct a new model of working
  • develop and offer participants conceptual tools for solving the above tasks

Expansive development cycle does not lead to a predetermined outcome, because the new model of work is not known when the process starts. It is negotiated and constructed during the process.

Cycle of expansive learning

1.2 Added Value of ICT Tools in Change Laboratory

As traditional Change Laboratory is an established practice, the benefits of the inclusion of ICT support must be analysed.

Virtual learning environment

In present situation the physical support for learning in CL are videotapings and a textual memo of the sessions. Various produced documents are not categorized systematically and therefore distribution, search and use of the documents are difficult. A virtual learning environment can help the participants to organize the process and produced documents and also facilitate discussion in a more tangible way.
  • Organizing process data and documents
CL system can be made to classify created data by time, date, event etc. in order to make the body of data more accessible for the participants.
  • Facilitating discussion
ICT allows the users to participate also in textual discussions compared to the (mostly) oral discussions of traditional CL. This will help in long-term discussions and development of ideas based on the discussions.

Virtual whiteboard

A specific application will be developed to facilitate the visual construction of new models and solutions in Developmental Work Research process. This setting is based on traditional “physical” whiteboard setting with extended features such as flexible editing and linking of concepts and digital material presented
  • Semantic annotation of presented and created material
Annotation and inclusion of semantics will enable new dynamic ways of representing the produced material and DWR concepts. This is very well in line with the dynamic nature of DWR process where common practices and the outcome of the process is negotiated and in constant change throughout the process.
  • Flexible editing of material
Compared to traditional whiteboards ICT support will bring more flexibility as intermediate steps of note taking can be made and edited during the discussions. Furthermore, already produced material is available for re-editing or copying.

Analysis toolkit

As the process is also research oriented, ICT support can be developed for multimedia annotation for analyzing video, audio, graphical and textual data using ontology of activity theoretical framework to perform preliminary analysis of activity by marking and classifying and linking relevant segments of data. Analysis supporting functions such as profiling of activities, predictive analysis of CL process, or glossaries of theoretical concepts may be implemented as enough material has been collected

2 Requirements

Expansive learning concerns the content of the process. The process itself if composed of the following phases:

  1. Project initiation – related to "charting the situation"
  2. Material Gathering – related to "analyzing the situation", "implementing the new model"
  3. Session planning – related to whole cycle depending on the phase of the process (interventionist plans the agenda and structures of sessions according to the cycle
  4. Conducting the sessions – see above
  5. Activities between sessions – see above
  6. follow-up and consolidation – related to "spreading and consolidating"

The above phases constitute from the following tasks divided to two different user groups.

Table: CL process by phases and user tasks

columns: User groups
rows:Process phase
Interventionist/Moderator tasksUser/Participant tasks
1. Project initiation and planningNegotiation and creation of process plan/agreement with target organization representatives?
2. Initial Material GatheringManaging and executing field observations: e.g. gathering notes, video recordings, documents, interviews. Storing material into repository. First analysis of the material.Co-operating with interventionist by providing relevant documents, arranging field observation possibility and interviews
3. Session PlanningCreating agenda for first CL session. Preparing material for the session. Revising process plan.?
4. Conducting a sessionModerating virtual or face-to-face session (meeting). Manipulating shared whiteboard. Taking personal notes linked to session activities. Assigning a secretary for producing session memo.Attending virtual or face-to-face session. Manipulating shared whiteboard (limited rights).
5. Activites Between SessionsManaging gathering of additional material: e.g. field observations, documents. Assigning tasks for users (homework). Conducting analysis of the material. Creating agenda for the next sessionCompleting assigned tasks (e.g. uploading material to the repository).
6. Follow-up and consolidationAnalysis of CL process and material. Producing reports and articles. Planning and conducting a follow-up session.Using material saved in the repository. Exporting material to organizations.

Tool requirements can be elaborated on the basis of the introduced tasks.

Table: Tasks and tool requirements

TaskTool requirements
Negotiation and creation of process agreement and process plan, revising process planProviding template for plan, editing the plan and saving documents into repository (GANTT + documents)
Managing and executing field observationsCreating a plan for material gathering (e.g. GANTT), storing material into repository, retrieving stored material, annotating stored material,
Making session agendaProviding a template for session agenda, editing session agenda, distributing agenda to participants.
Preparing material for sessionsRetrieving, editing and analysing material from repository. Preparing segments of material to be easily retrieved from the repository.
Conducting virtual of face-to-face meetingsFacilitating meeting moderation, collaborative note taking and virtual communication.
Manipulating shared whiteboardviewing notes and material on shared whiteboard, representing models and visualising relations between objects in the whiteboard
Conducting analysis of materialViewing stored material, creating ontologies and annotating material or segments of material (video, text) based on the created ontologies or existing ontologies.
Assigning tasks for usersMeans of assigning tasks for users (e.g. completing a questionnaire, writing a document)
Providing support for the processArchive of templates for relevant documents, scientific background material, guidelines etc. “Wizard” for supporting the process planning and analysis
Producing reports and articlesMeans of exporting relevant material to be used in production of project reports and scientific articles
Using saved material and exporting material to organisationsRetrieving material from repository and producing organisation-specific documents.

3 Functionality

The functionality of the tools used in a virtual Change Laboratory setting will be described in this chapter. The bulk of this functionality will be provided by the Shared Space GUI (SSGUI) and the Virtual Whiteboard, which is a Change Laboratory -specific tool. The combination of these tools, and any other tools that can be used in a Change Laboratory setting, will be referred to as the (working) environment. The tools will be implemented as Rich Internet Applications (RIA), which, from the user's point of view, means that they will be accessed through the use of a web browser. Any SSGUI functionality that does not relate to Change Laboratory is out of the scope of this document.

The first section will describe the central concepts in the environment that all the functionality will be based on. Later sections roughly separate the functionalities into groups (based on the activities inherent in a Change Laboratory process, described in the previous chapters) and describe them.

3.1 Central concepts

3.1.1 Application data model

Some of the data components

At the heart of the functionality in the Change Laboratory working environment is the division of the data that is being manipulated, as well as the data that structures other data, into specific types of objects. This is called the application's data model. The items that form the model are separated here into Structure-, Data- and Annotation items, based on the reason for their existence and the functions they provide. The design of this model aims to provide sufficient structure into the application, while being permissive enough so as not to restrict the wide array of uses that Change Laboratory workers and interventionists might have for it.

Structure items

These items create the basic structure that aims to mimic the actual composition of a Change Laboratory process. This is the structure that is provided to the classification of data that the users work with in the working environment.

  • A Change Laboratory process
    A Change Laboratory process is a series of sessions. It also includes other things, like homework (i.e. activity between sessions) and the planning of sessions, but the sessions themselves are the focus around which everything else in a process revolves around. In the working environment, a process is a single shared space - of a specific Change Laboratory type - in SSGUI.
    • Sessions
      A Change Laboratory process is mainly composed of sessions. All sessions contain the three areas described below, and may contain any number of themes (also described below).
      • Areas
        The three distinct areas are: Model & Vision, Ideas & Tools and Mirror material. These are used to classify data items based on their use in the context of a specific session.
      • Themes
        Themes are objects of discourse (or groups thereof) that are being discussed in the session.
        • States
          All themes have three states: past, present and future. States can not be added to, nor can any of them be removed.
    • Homework assignments
      Homework assignments are descriptions of groups of supplemental exercises that are to be done in a defined timeslot (usually between two sessions or a session and the beginning or the end of the process).
      • Homework submissions
        Structure-wise, homework submissions are very similar to sessions. They, too, contain the three areas and may contain any number of themes. They do, however, differ in functionality: sessions are generally held in a synchronous manner, whereas homework assignments are usually done and submitted more or less asynchronously. Furthermore, both have specific properties that the other does not.

Data items

Data items are objects that form the "meat" of the outcome of specific sessions, and of course of the whole process. They can be described as material that is being handled and/or produced within the course of the process. Data items can be set as belonging to one or more combination of a specific state, a specific theme, and a specific area, when an area belongs to a specific session or homework assignment (see image).

  • Triangle models
    Triangle models are objects that represent instances of the Change Laboratory activity system. todo: need picture here
    • Triangle model components
      A Triangle model has at least the following components: Instruments, Object, Subject, Rules, Community and Division of Labor. These "border labels" are the static components that are always present, visualized at the edges of the triangle. Any or all of them may have textual values. Between these border labels there can be "conflict" components: lines visualizing "friction" between the two endpoints.
  • Four-field models
    A Four-field model is a two-dimensional plane with four textual labels marking the left, right, top and bottom edges of the plane. Labels on opposing sides usually describe two different extremes of a certain subject, so that the model may represent the ranges between opposing extremes for two separate subjects - one per dimension. Any number of entries may be associated with a four-field model.
    • Four-field model entries
      An entry in a four-field model is a set of horizontal and vertical coordinates, marking a specific point on the plane, and with a textual label associated with it.
  • Notes
    Notes are simply snippets of text that can be of any length.
  • Content items
    A Content item is the basic concept of a piece of material with arbitrary content in the shared space.

Annotation items

In addition to the somewhat rigid structure provided by the "structure items", annotation items provide a more permissive way of classifying data items. They can be either Semantic Links (i.e. semantics that describe a relationship between two items) or Semantic Annotations (i.e. semantics that describe one specific item).

  • Semantic links
    Semantic links work in a similar way to the relationship links in the Shared Space GUI of the KP-Lab system: they are objects that connect two other objects and provide semantics to describe the connection. The description for a link can be selected from a pre-defined link vocabulary.
  • Semantic annotations
    Semantic annotations are objects that can be attached to data items to provide additional semantics. They always include a reference to a semantic term defined in a domain ontology.

3.1.2 User interface concepts

The user interface of the working environment in a Change Laboratory setting is the combination of the user interfaces of the tools being used - The Shared Space GUI and the Virtual Whiteboard. The user interface of the Virtual Whiteboard and the Change Laboratory -specific additions to the Shared Space GUI will be described here.

The Shared Space GUI

When in a Change Laboratory shared space, SSGUI has these main purposes:

  • To display the user a general summary of a Change Laboratory process in the context of the user's role in it.
    This summary is customizable by the user so as to promptly elicit understanding of the probably very large amounts of data that the process contains.
  • To act as a "launchpad" into the virtual whiteboard
    SSGUI provides controls for the user to navigate into specific sessions, homework assignments or homework submissions, each of which would then be opened in the virtual whiteboard. It always displays information for only one specific process (a process is a shared space), but does offer controls for navigating between different processes, provided that the user is a member in more than one.

GANTT chart with CL items

The Overview is the default view when opening the a shared space in SSGUI. In it, a GANTT chart is displayed, showing objects (tasks) in the shared space on a timeline. In a Change Laboratory shared space, objects specific to the Change Laboratory, such as sessions, homework and themes, will also be displayed here. Sessions and homework will be laid on the timeline according to their start and end dates, and themes will be positioned based on the times when they have been under discussion. The submissions from all of the members a specific homework assignment has been assigned to, and their state (submitted or not), will be visualized in relation to the assignment. Also, notifications are shown if any important properties are not set for CL-specific objects (for example, the agenda for a session or the description for a homework assignment).

The Virtual Whiteboard

The Virtual whiteboard is the view in which users can see and manipulate the contents of a specific session. It can also be used to view and manipulate homework assignments. The main elements of the virtual whiteboard user interface (see picture) are the following:

Virtual Whiteboard UI concepts

  • The Areas
    The three rectangular areas that take most of the screen real estate in the whiteboard UI depict the areas described in the Application Data Model section. They are each visualized with a distinct color. These areas work like containers in the sense that they can contain windows:
  • The Windows
    A Window is a representation of a specific state of a specific theme. All created themes have windows for each of its three states in each of the three areas, thus having a total of nine windows. When a data item is set as belonging to a specific theme/state/area combination, it is visualized inside the corresponding window.
  • The Timeline
    The timeline is a visualization of all the sessions in the process that the currently viewed session belongs to. It can be used to navigate between different sessions.
  • The Item Archive
    A List of all the data items that are available in the shared space that represents the current Change Laboratory process are presented in the Virtual Whiteboard in a list/tree format. This list - the item archive - can be used to drag and drop items onto the Whiteboard, and it is only visible to members with sufficient access rights to modify the current Whiteboard. The contents of the archive can be ordered based on several criteria, for example the session, homework assignment, homework submission and/or theme the item has been assigned to.

3.2 Managing the Process

3.2.1 Working with the Process Structure

A Change Laboratory process is initiated by creating a new Change Laboratory Shared Space in the Shared Space GUI. This is a shared space like any other in the system, with the vital distinction that it adds the possibility to use a few CL-specific features. The process is then planned, mainly by the creation of sessions, tasks and themes.

The interventionist who plans the process can make use of task objects in the shared space to plan chores like material gathering and session preparation. Sessions themselves are added to the process by creating them as objects in the shared space, quite like tasks. In addition to sessions and arbitrary tasks, the interventionist can also plan the themes to be discussed by creating objects for them in the Shared Space GUI. These can then be added to a session by use of a hierarchical link (i.e. "this session contains this theme"). For each session, the interventionist may write a textual agenda (the full agenda of a session may be perceived to be composed of both the textual agenda and the themes assigned to be discussed in the session), the lack of which the working environment will notify to the user both in the Virtual Whiteboard and in SSGUI by use of descriptive icons.

3.2.2 Managing Users and Rights

When someone creates a shared space in SSGUI, they become the creator and the administrator of that space by default. Similarly, when a Change Laboratory shared space is created, the creator is set as the creator of that space and the interventionist in the process depicted by the shared space in question. The interventionist is, thus, the administrator of the space.

The tool for managing user rights in a CL shared space is the same that is used in managing any other shared space: the Shared Space Management Tool. Using it, an interventionist may:

  • Add members (i.e. workers) to the shared space
  • Assign rights to members
  • Assign other members as interventionists

The interventionist has access to everything within the space. Workers, on the other hand, have only read access to most objects, not including objects they themselves have created, or objects that have been explicitly set as modifiable by any member. The same access rights are in effect in SSGUI and the Virtual Whiteboard.

3.3 Handling Data Items

Creation, Deletion and Copying

The data items that can be used in the Virtual Whiteboard are all, with the exception of the model items, visualized also in SSGUI. This is why triangle- and four-field models can be created only from the Virtual Whiteboard, but all other data items can also be created from SSGUI. When an item is created in the Virtual Whiteboard, it always has to be assigned to at least one of the three areas (see "Assignment" below).

Deletion of items is always done through SSGUI. In the Virtual Whiteboard, items can be removed from the current Whiteboard, but that does not delete the items, but simply removes their assignment in the current session, homework assignment or homework submission.

Items can be copied from one Whiteboard to another either from the Whiteboard that contains the item or from the Whiteboard where one wishes to copy it to. In the latter case, the copying is achieved through the use of the item archive. When a copy is created, the same assignment rules apply as in the case where a new item is created from scratch. A Whole theme may also be copied from one Whiteboard to another, which copies not only the theme, but also all the items associated with its three states. Semantic links or semantic annotations can not be copied.

Assignment

In the Virtual Whiteboard, items are always assigned - by dragging and dropping them from the item archive - to either:

  • An area, theme, state combination
    As the Virtual Whiteboard visualizes these combinations as windows, when an item is assigned to one of them, they will be, in the user interface, placed inside the window container.
  • One of the three areas
    If an item is simply assigned to an area, it will be placed inside the area container in the user interface, and not inside any window.

If an item is not assigned to either of these in the Virtual Whiteboard, they are not part of (or assigned to) the current session or homework assignment/submission, and the only way to access them is through SSGUI or the item archive. To assign an item, one is required to have access rights to read the item and to manipulate the object that the Whiteboard represents (session or homework assignment/submission).

Viewing and Manipulation

Items that have no visualization of their contents in the working environment user interface (e.g. arbitrary content items) can be opened with any application on the local workstation that supports the file format. This entails downloading the file with the web browser and selecting the application that the file will be opened with. If any changes that the user wishes to retain are made to this file, it must be re-uploaded to the system through SSGUI, replacing the data for that particular content item.

When a triangle model is added to the Whiteboard, all of its border labels will be present and without a value, which means that they will display the generic description of their meaning in the model (i.e. Instruments, Object, Subject, Rules, Community or Division of Labor, respective to location). That description will be replaced by a textual value as soon as one is added. Any of the border labels can be hidden in order to remove concepts that are irrelevant to that specific model's purpose, regardless of whether or not they have a value. In each triangle model there can be a maximum of one conflict component per relationship between two of the border labels. A Conflict component may also have a textual value (i.e. description).

In its default state, a four-field model has a default description (for example, "untitled" or "N/A") for each of the four labels on its edges. The values for these may then be changed, and entries may be added. An entry is added by clicking on a specific location on the model's plane and then typing some text as the label.

The notes in the Virtual Whiteboard are similar to ones in SSGUI functionality- and user interface-wise; they are blocks of text with basic formatting abilities, such as font selection (typeface, bolding, italics, underlining) and coloring.

Any of the triangle models, four-field models or notes can be exported from the system. Models are exported as bitmap or vector graphics files, and notes are exported in HTML format. The export functionality is invoked from the Virtual Whiteboard, and then the exported file will be downloaded to the local workstation with the web browser.

Annotation

Annotations pertain to distinct data items, data item components, or combinations of a theme, its state, and an area. For example, a semantic link can be created between a "subject" component in a triangle model and the "past" state of a theme in the "Mirror material" area.

Both semantic annotations and semantic links rely on a vocabulary, which for semantic annotations is called the domain ontology, and for semantic links the link ontology. These vocabularies are specified in SSGUI on a shared space basis, which means that every Change Laboratory process may have its own vocabularies. When an annotation is created, whether it be a semantic annotation or a semantic link, a vocabulary term must be chosen from the corresponding vocabulary to describe that annotation.

Semantic annotations are created and visible only in SSGUI. Semantic links, on the other hand, can be created both in SSGUI and the Virtual Whiteboard. All links created in the Virtual Whiteboard are visible in SSGUI, unless one of the link endpoints is an object that is not visualized in SSGUI (such as a model object or a model object component). A link created in SSGUI is visible in a certain Whiteboard only if both of its endpoints are assigned to and set as visible in that Whiteboard.

3.4 Carrying out the Process Work

3.4.1 Sessions

The sessions in a Change Laboratory process are, by definition, synchronous. This means that all participants are present and collaborating in real-time. In practice, this may mean either that everyone is sitting in a single room, using one computer for accessing the Virtual Whiteboard (this is a local session), or in separate remote locations, each with their own computers and connections to the KP-Lab system and the Virtual Whiteboard (this is a decentralized session). Sessions require and rely on discussion between the participants, which, when the session is decentralized, means that a video-conferencing application would need to be used.

The two session types

The Virtual Whiteboard enables real-time work on its contents by synchronizing all activity between all currently connected clients. This is always enabled by default when participating in a session. The idea is that the interventionist, who is by default the only one with access rights to everything in the process shared space, would manipulate the contents of the Virtual Whiteboard during the session while everyone else could see what is happening. In a local session this can be achieved, for example, by projecting the computer screen's contents onto a canvas on the wall.

In addition to manipulating the contents of the Whiteboard, the interventionist will also have a couple of specific features to enable her to involve the other participants a bit more in the flow of the session: highlighting and temporary elevation of access rights. Highlighting is simply a means of selecting one or more specific elements in the Virtual Whiteboard and make their borders glow with a bright red color, informing the participants of where their attention should be diverted to. Temporary elevation of access rights is a feature that makes it possible to grant specific users temporary rights to manipulate objects in the Whiteboard. This can be used, for example, to enable the workers to report their ideas or findings directly to the Whiteboard after discussing a subject by request of the interventionist.

When the session has finished, the interventionist will mark it as such from the Virtual Whiteboard controls. The final state of a session will then be saved. A Memo is supposed to be written for each finished session, and the interventionist will be prompted to write it when the session ends. She can either accept or deny this request, and write the memo later if she so chooses. If a session is finished and no memo has been written, a notification about this will be shown both in the Virtual Whiteboard and in SSGUI.

3.4.2 Homework

Homework can be assigned to workers by the interventionist by first creating a homework assignment and then assigning it to one or more members of the CL process. An assignment is created from SSGUI, and it will be visible as an object there. Start and end dates for the assignment mark the interval when the task of submitting the homework should be completed, and a textual description outlining the purpose of the homework can be written. The interventionist may then edit the assignment itself by opening it up in the Virtual Whiteboard and adding content into it to create a starting point for the submissions. The assignment is then assigned to workers through SSGUI.

When a worker is assigned homework, it will be visible to them in SSGUI, along with all metadata associated with it (for example, the assignment's description and any other workers whom it has been assigned to). They may then start working on their submission by opening the assignment in the Virtual Whiteboard. They will initially be presented with the starting point the interventionist has created, and may then finish their submission by adding, removing and manipulating content on the Whiteboard and finally marking their submission as finished. They may enter and exit the Virtual Whiteboard of their submission as many times as they wish, as long as it has not been submitted - the homework need not be finished in one sitting.

The most fundamental difference between sessions and homework is that while sessions are always synchronous, homework will only be synchronous when needed, and otherwise asynchronous. This is based on the fact that while the concept of a session requires that the participants be present at the same time, and thus collaborate synchronously, homework only requires that submissions for assignments be submitted within a specified time. The workers to whom a certain homework assignment has been assigned to may thus collaborate by working on the assignment in the Virtual Whiteboard either synchronously (that is, working on the homework at the same time, either locally or in a decentralized manner) or asynchronously (that is, working on the homework at different times by themselves), as long as the end result is that the Whiteboard be in a state that can be submitted.

4 Architecture

4.1 Application Components

The most essential application architecture design principle in designing the Change Laboratory tools is to avoid redundancy and reuse as much as possible from existing KP-Lab (and third party) tools. The decision to use the Shared Space GUI and integrate some CL-specific functionality into it was made early on. While some of the functionality that is needed in a Change Laboratory process can be implemented in SSGUI, some of it warrants a separate application - the Virtual Whiteboard.

The application components

Change Laboratory -related functionality will be added to SSGUI via a plug-in application programming interface (API). This enables SSGUI to remain as-is, and all CL-related features to function and be developed independently of SSGUI's "built-in" features. The Virtual Whiteboard application will function as an independent web application, but it will communicate with SSGUI via external client-side APIs in both. It will use the common KP-Lab synchronization service to implement its real-time synchronization features.

Both the Change Laboratory SSGUI plug-in and the Virtual Whiteboard will communicate with the same server-side component, the Change Laboratory service, in order to retrieve and manipulate data in the Knowledge Repository (KR).

4.1.1 The GUI Components

The SSGUI plug-in

The features that the Change Laboratory plug-in adds to SSGUI are the following:

  • Retrieving CL-specific data from Knowledge Repository
    As SSGUI does not display or even know about CL-specific objects, the plug-in has to be able to implement loading data about them and integrating that data into the internal graph model that SSGUI uses to store the data it has about visualized objects.
  • Displaying and controlling CL-specific objects
    When the CL-specific objects are properly represented in SSGUI's graph model, the plug-in has to implement the classes that visualize them (as nodes in the zoomable user interface (ZUI) plane and rows in the GANTT chart) and control their behaviour.
  • Translation from graph model to visualization
    The rationale for creating visualized objects (for CL-specific object types) based on graph data contents has to be implemented to be able to get them to show up in the UI.
  • Manipulating CL-specific objects
    The methods for creating, deleting and modifying CL-specific object types have to be implemented. This entails linking the object classes to specific functionalities in the operations libraries and then implementing those functionalities (by communicating with the Change Laboratory Service and making additions to the graph model based on results).

Virtual Whiteboard

The Virtual Whiteboard will be implemented as a Flash application and built with the Adobe Flex framework. It implements an external client-side API to enable other client-side applications or components to send messages to it. There are two ways to call the methods in this API:

  1. Calling JavaScript functions on the page that contains the Virtual Whiteboard
  2. Calling the methods through Flash Player's LocalConnection class

The following are the methods in the Virtual Whiteboard application's external client-side API:

method signaturedescription
goToWhiteboard(string processURI, string whiteboardURI)Changes the currently shown whiteboard environment
refreshView()Forces the application to update its data from the server

In addition to these, the following HTTP GET parameters can be passed to the application in order to initialize its first view:

parameter namevalue formatdescription
whiteboardURIURIThe URI of the whiteboard environment to initially open
processURIURIThe URI of the CL process (shared space) that contains the Whiteboard to be opened

The Virtual Whiteboard uses the client-side synchronization service for two purposes:

  1. Synchronizing its internal data between connected clients to enable real-time synchronization of all data that is being manipulated in the Whiteboard.
  2. Listening for events that relate to objects visualized in the current view so that if someone manipulates an object in SSGUI, the effect will show in the Whiteboard.

4.1.2 The Change Laboratory Service

Both the Virtual Whiteboard and the Change Laboratory SSGUI plug-in use the Change Laboratory Service to operate on data in the Knowledge Repository. This communication will be implemented either as HTTP GET requests (with returned data as XML) or as web service requests with SOAP.

The Change Laboratory Service may use either the Persistence API or KMS Request Engine to communicate with the Knowledge Repository. While the former is a Java library that returns Java objects based on queries to the database, the latter is a Web Service and returns RDF/XML. It also communicates with the Shared Space Rights Management Service to mark data with the proper access rights flags based on the current user's rights, and with the Knowledge Annotator tool to manage semantic annotations and semantic links.

Preliminary API

getWhiteboardContents
Returns the contents of a specified whiteboard environment

parameters:

Name Value type Description
userURI URI The URI of the current user
whiteboardURI URI The URI of the whiteboard environment the contents of which are to be returned
processURI URI The URI of the process the specified whiteboard belongs to

getCLObjects
Returns the CL-specific objects contained in a specified shared space (and optionally also container or image map)

parameters:

Name Value type Description
userURI URI The URI of the current user
sharedSpaceURI URI The URI of the process (i.e. shared space) the contents of which to load
containerURI URI The URI of the container the contents of which to load (optional)
imageMapURI URI The URI of the image map the contents of which to load (optional)

createObject
Creates an object (a four-field model, a triangle model, a content item or a note)

parameters:

Name Value type Description
userURI URI The URI of the current user
objectClassURI URI A URI specifying the system model class of the object to be created
title string The title for the new object
description string The description for the new object
+ parameters for specific initialization properties for different object types

deleteObject
Deletes an object (a four-field model, a triangle model, a content item or a note)

parameters:

Name Value type Description
userURI URI The URI of the current user
objectURI URI The URI of the object to be deleted

modifyObject
Modifies properties of an object (a four-field model, a triangle model, a content item or a note)

parameters:

Name Value type Description
userURI URI The URI of the current user
objectURI URI The URI of the object to be modified
+ parameters for the modified values of specific properties for different object types

setObjectAssignment
Assigns or unassigns an object (a four-field model, a triangle model, a content item or a note) to/from a specified window container in a specified whiteboard environment

parameters:

Name Value type Description
userURI URI The URI of the current user
objectURI URI The URI of the object to be assigned
whiteboardURI URI The URI of the whiteboard environment to assign the object to
processURI URI The URI of the process the specified whiteboard environment belongs to
themeURI URI The URI of the theme to assign the object to
area string Which area to assign the object to ("modelVision", "ideasTools" or "mirrorMaterial")
state string Which state to assign the object to ("past", "present" or "future")
unassign boolean Whether to assign (false) or unassign (true) the specified object from/to the specified whiteboard environment
xCoordinate integer The horizontal coordinate of the object in its window container
yCoordinate integer The vertical coordinate of the object in its window container

createSemanticLink
Creates a new semantic link

parameters:

Name Value type Description
userURI URI The URI of the current user
processURI URI The URI of the process that contains the new link
startObjectURI URI The URI of the object where the link starts from
endObjectURI URI The URI of the object where the link ends
description string or URI The description for the link: can be a string (for a "free-text" description) or the URI of a term in the link vocabulary of the current shared space (or process)

deleteSemanticLink
Deletes a semantic link

parameters:

Name Value type Description
userURI URI The URI of the current user
processURI URI The URI of the process that contains the link
linkURI URI The URI of the link object to delete

modifySemanticLink
Modifies the properties of a semantic link

parameters:

Name Value type Description
userURI URI The URI of the current user
processURI URI The URI of the process that contains the link
linkURI URI The URI of the link object to modify
description string or URI The description for the link: can be a string (for a "free-text" description) or the URI of a term in the link vocabulary of the current shared space (or process)

setWindowState
Sets the state of a Virtual Whiteboard "window" (CLWindowRepresentation in the system model)

parameters:

Name Value type Description
userURI URI The URI of the current user
windowURI URI The URI of the specified window
whiteboardURI URI The URI of the whiteboard environment that the window belongs to
processURI URI The URI of the process the whiteboard environment belongs to
xCoordinate integer The horizontal coordinate of the window in the UI
yCoordinate integer The vertical coordinate of the window in the UI
width integer The width of the window in the UI
height integer The height of the window in the UI
visible boolean Whether the window is visible or hidden
minimized boolean Whether the window is minimized or not

4.2 System Model

The Change Laboratory tools will use the same data store as other tools in the KP-Lab system: the Knowledge Repository. This means that some changes have to be introduced to the ontology that defines the database structure - the system model.

The Change Laboratory additions to the KP-Lab system model

  • todo: describe the above

5. Conclusions

  • the specifications-gathering process
    • problems encountered
    • positive notes
  • future developments
    • notes on collaboration (with whom, on what, how to succeed)
    • further features
      • semantic multimedia annotation tool integration ???
      • map-it integration ???
      • templates



Categories: Development Development Change Laboratory

Attachments

DWR setting.png Info on DWR setting.png 107994 bytes
activity-system.gif Info on activity-system.gif 3020 bytes
asetelma.png Info on asetelma.png 24242 bytes
components-small.png Info on components-small.png 125355 bytes
cycle.gif Info on cycle.gif 5215 bytes
data_objects_small.png Info on data_objects_small.png 58023 bytes
gantt-small.png Info on gantt-small.png 100021 bytes
mock-up1.5-preli-text-small.png Info on mock-up1.5-preli-text-small.png 64329 bytes
sessiontypes-small.png Info on sessiontypes-small.png 54172 bytes
sessiontypes.png Info on sessiontypes.png 439293 bytes
systemModel-small.png Info on systemModel-small.png 251459 bytes
whiteboard-small.png Info on whiteboard-small.png 73450 bytes
  Page Info My Prefs Log in
This page (revision-121) last changed on 18:24 25-Mar-2017 by FrantisekBabic.
 
JSPWiki v2.4.102
[RSS]