Teams, Tasks, and Notices: Managing Collaboration via the World Wide Web

Abstract

The World Wide Web has advanced from a "read-only" medium to supporting local publishing, then distributed authoring, and soon distributed collaboration. In this paper, we present an experimental system we have developed that incorporates novel ideas of notification, visualization, and extended Web services to support the creation, management, and effective use of collaborative workspaces with the World Wide Web.

Introduction

As originally conceived by Tim Berners-Lee in the early 1990s, the World Wide Web supported the reading of content and the creation and publication of content as well. This support has not been generally available because most HTTP server vendors do not implement the PUT HTTP method, but during the past year, several commercial vendors have created support for Web products for the remote authoring of content, including products such as Microsoft's FrontPage editor [Frontpage] and Netscape's Navigator Gold browser/editor [Navigator]. In addition, systems like BSCW [Bentley95] have publicized the notion of workspaces, where remote collaborators can publish, review, and critique the work of other members of their project.

Such collaborative workspaces are especially important in an Intranet environment. An Intranet environment refers to the use of Internet technology in the setting of a single organization, such as a particular company or university. Restricting the environment to a smaller and well-defined organization allows individual users to be known, policies to be set, and consistent administration of the Web to be performed. A shared workspace in an Intranet environment may take advantage of these restrictions to provide a more effective environment for information sharing.

It is clear, however, that distributed authoring is not sufficient to support true collaboration: rather, we need support for commentary, annotations, and the ability to inform others of our progress via timely notifications. Improvements to existing Web environments must occur both via enhanced Web services and via better desktop tools to access and manipulate that environment. We liken this Intranet environment to a workshop where skilled craftspeople have their own stations and tasks, but where these stations and tasks are interlinked in various ways. Key to our notion of an Intranet workspace is the representation of business objects (the work itself) and the flow of work as various kinds of hypertext structures, where the nodes represent various items of work, and the links represent relationships between these work-items.

One important class of business of objects are project documents representing individual project deliverables or sets of tasks. These documents may be registered into the shared workspace at any time and assigned to categories to make retrieval easier. Each document has an owner, but may be passed from individual to individual for modification. Documents have states, such as created, revised and sealed (no changes permitted). Documents have subscription lists of users associated with them, permitting notifications to be sent to interested parties upon document state changes. Subscribing parties may be individuals or applications (principals), and these parties may take various actions upon receiving these notifications.

It is the notion of asynchronous notification that ultimately supports the ability to monitor the work being performed within this workspace. As an example, consider a typical review and authorization process. A special reviewers list is generated for each document (which is associated with a task). When a task is completed, the document is marked as submitted, and each reviewer is notified. Approval can be indicated by returning an approval notice. Once all reviewers have approved the document, the task is now marked as completed and the document may be sealed (indicating no further changes), an action which generates another round of notifications.

Scenario

The above environment is suitable for many different team organizations, including business and education. A simple scenario, drawn from the education domain, both illuminates and motivates our work. This scenario follows three students as they work to complete their term project in a class on mobile distributed programming.

Alice, Bob, and Carol are members of a class on mobile distributed computing using Java. The class has a website which has documents and student information managed by an extended Web service called the Mediator [Mediator]. Their portion of the Web site contains readings for the class, assignments, information about individual students and groups they form, and is also where the students deposit their homework. The Mediator provides access control such that class readings and assignments can be read by all the students but only modified by the instructor; homework can only be read by an individual student and the instructor.

The instructor assigns the final project for the class by creating a document describing the project; the final project involves forming teams of 3-4 students to design and implement a Java applet and associated classes. In this case, a set of the applets will work together to provide a "guided tour" of the Web. One applet allows an individual to act as a "tour leader" to provide a "guided tour" of a particular Web space; the other applets allow tour members to "follow along" via their browsers.

Whenever a document is added or modified within the document space controlled by the Mediator for the class, a notification is multicast to anyone who has subscribed to these Mediator notifications. The student's Web activity visualizers can be set up to receive these notifications and display them by adding or modifying the node in the display corresponding to the document. Other tools can also be made aware of the notifications: for example, Alice has configured her environment so that notifications about new assignments will cause an alert to pop up on her screen. Eventually, all the students receive notification when the project document is added.

Alice, Bob, and Carol have already been studying together for the class and decide to form a team for the final project. They use the Mediator to register their new team: this sends out a notification to which the instructor is subscribed. She annotates their team registration to approve the formation of their team and to provide some additional suggestions specific to their group.

First they have to design the architecture of their applet. They start by configuring their activity visualizers to browse into a single shared history. They browse individually for a while to find documents they think relevant to the design. They then work together to prune and organize their history into a coherent tree and to add annotations noting important portions of the documents. They save this tree via the Mediator so that they can refer to it during the rest of the design process and implementation process as well as including it in their final report. The team then jointly generates and works on a single document describing the design of the applet, and saves it via the Mediator as well.

They then begin the implementation phase. They split the work up such that Alice implements the main applet, Bob implements the classes related to coordinating among the members of the tour, and Carol works on user interface classes. The code they write goes into documents which they can check into the mediator, sending out notifications. So, for example, Alice can know when Bob has checked in a version of the coordination classes that he thinks are running properly. She can then include his latest code in her applet and test it out.

By making use of the notification recording facility, they can even coordinate their work when not logged in. So, for example, when Alice goes away for the weekend, she invokes the "Record Notices" function before she leaves. Carol comes in over the weekend and completes an important user interface class that Alice needs. When Alice begins working on the project again on Monday, she invokes the "Retrieve Notices" function, retrieving any stored notifications including the notification about the new UI component, which she sees that she can now begin using.

Finally, they are done implementing and testing and have to deliver the project to the instructor. They create a tree providing a tour of the project. They save and check this in to the Mediator, and mark all their pieces as done. The Mediator automatically sends out a notification which lets the instructor know when everything is complete.

Grading is straightforward. The instructor follows the tour and verifies that the applet meets all of the requirements. She adds some annotations noting some elegant features in the design but also noting an unstated assumption that could lead to problems in certain unusual conditions, and records their final grade as an annotation to the team's task document (readable and writable only by the team and their instructor).

Architecture, Design and Implementation

The previous scenario described how a group of individuals could function effectively as a team in an Intranet Web environment. This environment implemented a system architecture consisting of desktop applications, group services and a notification framework.

Desktop Applications

Our desktop applications consist primarily of browsing associates: small, simple applications (compared to Web browsers and servers) which are not coupled to particular HTTP streams and can independently and asynchronously access the Web on the user's behalf. Our associates often take advantage of browser interfaces to observe user browsing actions, but this is not a requirement.

Each team member generally works with a number of Intranet web pages, and, in addition to viewing individual pages, will want to visualize the group of pages as a whole in a manner which makes sense to them. The Web Activity Visualization System allows a user to see a graphical tree representation of Web sites they have visited and which are of interest to them. The user may manipulate this tree, work with the pages shown in the tree, and receive notifications in this visualization. We have implemented a prototype of this system called HistoryGraph [Hirsch97]. HistoryGraph may be used in conjunction with our WhatsNew[Brooks95] browsing associate for monitoring changes in the Web.

The main HistoryGraph display consists of nodes representing visited URLs and links representing the order in which URLs were visited. The nodes consist of small icons followed by an elided title or URL. The standard icon is a simple file folder icon and indicates no additional information about the page. Additional icons are used for nodes with additional information, such as the document icon () which shows a document which is stored in our Mediated access service, and the stack of documents icon () for an index of Mediated documents. The "sealed" icon () indicates that the document has been sealed and can no longer be modified. (The icon is meant to represent an old-fashioned sealing wax seal.)

In addition to a history mechanism, HistoryGraph provides a means for using and manipulating the visualization. The nodes may be rearranged by dragging with the mouse, and nodes may be removed, so that the representation is meaningful to the user. Each node represents a web site, and has a URL and title associated with it, as well as other properties (such as annotations or the number of times visited). HistoryGraph also provides the means to create sets of nodes. These sets may be created automatically via pattern matching on the tree, or may be created when a notification is received. Once a set is created, it may be sent to another desktop application for processing. Likewise, individual sets and entire trees can be saved and retrieved from local storage or via the Web: an assignment of a MIME type (application/X-historygraph) permits these trees to be automatically loaded into the Visualizer.

HistoryGraph is able to receive notifications from other desktop and group applications, and use these notifications to update the tree display, change the icons for documents, and update sets and properties. One group service which sends notifications is the Mediator, to indicate the change of state for documents.

Group Services

The Mediator is a prototype which incorporates two group services: The Web Page Control System and the Team Management system. The main purpose of a Mediated shared web is to make it easy for individuals and services to discover what documents are available and to easily track and synchronize document changes and group activities.

The concept of a Mediated shared web extends beyond simple HTML documents and encompasses two additional notions. The first is that the document space may include more active content such as CGI programs, Java code, or Web activity trees, and that these too may have states, owners and access controls. The second notion is that information about the members of the team can be stored in a central repository: this allows greater coupling between the team's documents and members, such as associating document permissions and classes of notification with individual members or subgroups of the team, and well as allowing this information to be accessed by multiple applications

The Web Page Control System is used to control access to Web documents, maintain versions of these documents, and manage their state information. Mediated documents are pages which have owners and controlled access. The Mediated access service provides an index of documents as well as producing the original documents to authorized users when requested.

The Mediator may be used to create a "shared web", which is a set of web documents that have state, owners, and access controls. Each document may be modified by one team member at a time, until the document is sealed, at which point it may no longer be modified. The person who is currently authorized to modify the document is known as the delegate.

The shared document space has a structure associated with it, including a project page which organizes documents by their relevant categories, a team page which lists team members, and a document index which lists documents, their states, and associated projects. In practice, we have found the document index most useful.

The Team Management System is used to provide a directory of information about team members as well as to associate document permissions with members. Our prototype of this system is called "The User Profile Service" and is accessed by a number of group services, including a document annotation service[Schickler96].

Notification Framework

The Notification System is used to multicast event notifications which can be received by various programs. Most commonly these programs simply display information about a notification to an individual user, but they can also take more sophisticated action, including sending out further notifications. Within the context of our Intranet workspace, these notifications are used to inform team members of the creation or deletion of documents, as well as document content and status changes. Notifications are sent to location-independent names, may be stored on behalf of disconnected users, and may be ignored by users who decide not to subscribe to categories of notifications. We have implemented a prototype of this Notification System [Meeks97].

Our system provides two types of notification services. The first is a notification package that works by linking with the Zephyr Notification System [DelaFera87], developed as part of MIT Project Athena. Zephyr provides a notification system which is location independent (messages are sent to the name and the system deals with finding the recipient), and subscription based (recipients may choose whether or not to receive notifications of various types). The service provides a high level abstraction layer for automatically subscribing and unsubscribing to notices, for handling notices as they are received, and for synchronizing responses to notices.

The second service is a notification recording service, which is built on top of a network blackboard. The network blackboard is simply a shared information space which can be accessed using the notification package and a standard set of functions to read and update the information space. Because the notification package is used to communicate with the blackboard, it can be accessed from applications without the applications having to know where it is located. More importantly, though, the blackboard can act as a surrogate for another application that is temporarily disconnected from the network, storing notices for later delivery when the application reconnects. The notification recording service does this by having the blackboard subscribe to the same set of notices that the application wants to receive.

Using the notification package and recording service allows desktop and group applications to easily send notifications of various categories, which then may be easily received and displayed by multiple users and services which subscribe to those categories. Entities which occasionally disconnect from the Intranet can continue to participate in the notification process by having their notices saved for later retrieval.

Conclusion

The next stage beyond writable Webs is the ability to support sophisticated collaborative applications. Advancing to this stage requires two major improvements. The first is enhanced Web services that support notification of change to underlying Web objects, the management and query of meta-data concerning the various objects managed by a given Web service, and the application specific modification of documents as they are stored and fetched from the server. The second improvement cosist of desktop tools that enhance browsing activity and collaboration: these tools will offer close integration with existing browsers and can leverage the browser's ability to both fetch and display content. Powerful subscription-based notification systems can integrate the desktop tools with these enhanced Web servers, and can be used to quickly generate new application services that enhance the browsing experience, the generation of content, and the management of project activities. Such capabilities are already on the horizon: Netscape Communicator will support the paradigm of "netcasting", where users can automatically receive message, applications, and updated Web site information, and can organize, view, respond to such information as they see fit [Netscape97]. We believe that experimental systems such as described above can both illustrate the need for such systems as well as illuminate the capabilities and directions that such systems will ultimately take.

References

Last modified: Mon Mar 3 11:47:50 EST