Collaborative Technology Overview
NAVCIITI Project
Virginia Tech Center for Human-Computer Interaction

Collaboration has become a critical element of the NAVCIITI project, and ongoing work across several of the NAVCIITI groups has examined two distinct kinds of collaborative problems: sharing of continuous streams of sensor or visualization data, and synchronous and asynchronous collaborative authoring and communication of discrete data. These two types of collaboration are complementary. Sharing of streaming, continuous data allows collaborative interactive visualization of real or simulated events, while authoring and communication tools support strategic collaborations that surround these interactions and allow knowledge to be extracted from them. Many of these collaborations involve shared viewing and editing complex data objects in real time. Most also require transparent integration of synchronous and asynchronous collaboration. Although complementary, the two types of collaboration require software that operates under very different assumptions and constraints with respect to speed, reliable transmission, and data persistence. (Additional information on CORK can be found here.)


Figure 1. Synchronous and asynchronous distributed collaborative authoring.

Work undertaken by the Center for HCI as part of the NAVCIITI project has focused on design, development, and evaluation of software components to support a variety of synchronous and asynchronous collaborative activities. Figure 2 illustrates the general structure of our software efforts.

client-server-layers.jpg
Figure 2. Architecture Overview.

Our Content Object Replication Kit (CORK) provides infrastructure for data replication among collaborating clients. To simplify creation of new collaborative tools or adaptation of single-user tools for collaborative use, CORK supports attachment of listeners to Java objects that can detect local state changes and propogate those changes using a lightweight messaging scheme over sockets or HTTP connections. (Secure socket and datagram transmission could also be supported in the future.) Persistent copies of replicated objects are stored on a server to support asynchronous interaction and late joiners. The default storage mechanism saves objects as XML files, and alternate storage implementations may be plugged into the CORK server. User authentication is also pluggable, allowing integration of existing authentication services. Access to objects can be restricted, as can permissions to modify objects. Modification permission may be at any level of granularity, allowing schemes in which a given user is only permitted to make certain changes.

On top of CORK we have developed a number of collaborative components such as shared drawing tools, synchronous text editors, annotatable interactive maps, chat sessions, data tables, charting tools, and threaded discussions. Demonstrations of a number of these components are available at http://java.cs.vt.edu/Public/View/CHCISoftware/. Figures 3, 4, and 5 show several of these components.

wb-conf-win.gif

Figure 3. Shared whiteboard.

The shared whiteboard shown in Figure 3 is based on the open-source JHotDraw (http://www.jhotdraw.org/) drawing tool. A user list indicates which other users are accessing the object.

chat-conf-mac.gif

Figure 4. Chat session. CORK-based chats are persistent, collaborative documents that can span multiple sessions and be archived for later reference.



Figure 5. Collaborative map annotation tool, with collaborative text objects attached to map spots.

Recent work on focused on infrastructure for environments that support flexible composition of CORK-based components to meet emergent requirements along with services that can be shared across components. Basic Resources for Integrated Distributed Group Environments (BRIDGE) provides tools for mapping CORK objects onto interactive and web-accessible user interface components, combining components into environments, and providing awareness and notification tools. BRIDGE has been designed to support three kinds of composition of collaborative content:
  1. Textual composition, for publishing and archiving of collaboratively generated content. This allows content to be put together in a web-accessible form so that it can accessed from any device with a web browser. It also allows other technologies such as searching and indexing tools designed to operate on web content to be leveraged for use with CORK-based content.
  2. Graphical composition, for collaborative markup. This provides a mechanism for combining static images or content rendered from charts, maps, and other graphical components on a whiteboard to support markup activities.
  3. Interactive composition, for focused collaboration. This supports construction of environments for collaborative interaction with specific sets of collaborative objects.

Figure 6 shows one possible incarnation of a BRIDGE-based workspace running on Mac OSX and Windows.

   

Figure 6. A BRIDGE-based workspace for interacting with a set of collaborative objects. (Click to see full-sized image.)

In this example, two users are interacting in a workspace to troubleshoot a problem with a pump and document the result. They are communicating via chat, authoring a document in a synchronous text editor, and marking up a diagram of the pump on a whiteboard. The workspace shows a user list, a list of objects relevant to the task, a chat session, and a shared desktop. Objects from the object list may be opened on the shared desktop, where all participating users will see the windows at the same locations, allowing users to more easily refer to shared content. All material created in the workspace -- text, chat transcripts, and whiteboard content -- is web-accessible, subject to permisions settings.

BRIDGE components (either composite tools like workspaces or individual objects) can be launched by clicking a link on a web page. This allows users to arrange synchronous interactions by simply sending a url to potential collaborators. As with all CORK-based components, objects can be used either synchronously or asynchronously. Each window in a BRIDGE-based environment can show permissions information, a list of users currently accessing the object, and a URL for retrieving the web-accessible version of the object. BRIDGE also provides infrastructure for automatic or manual creation of object versions.

The goal of BRIDGE is not just to provide a specific collaborative workspace environment, but rather to provide abstractions and standard services to support a variety of environments. A BRIDGE environment could be constructed that provided a static arrangement of a specific set of tools, arranged in a specific way for a specific purpose. For example, if a common collaborative activity involved a group of distributed users annotating a map, chatting about the map data, and preparing a report, a simple environment could be built that provided access to just those three tools in a streamlined fashion.

With scripting capabilities, BRIDGE can also be used to attach collaborative capabilities to otherwise non-collaborative tools. For example, a specialized database query tool could be extended to include "help desk" functionality by attaching a BRIDGE-based user list and chat session.


/public/projects/navciiti/Technology Login | Web Editor | Full Editor
Last modified 4/30/03 8:48 PM by isenhour (history)
Site contents