Document presence notification services for ... - IEEE Xplore

0 downloads 0 Views 925KB Size Report
Instant messaging applications that convey presence awareness are quickly becoming some of the most popular groupware applications. They support.
Document Presence Notification Services for Collaborative Writing Alberto L. M ~ r a n " : ~Jesus ) , Favela(2),Ana M. Martined3), and Dominique Decouchant(') ( I ) INPG, Grenoble, France, (2) CICESE, Ensenada, B. C., Mixico, (3) CINVESTA V-IPN, D.F., Mdxico, (4) FC- UABC, Ensenada, Mdxico. Alberto.Moran@imag$r, [email protected], [email protected], Dominique.Deco u [email protected] r Abstract Instant messaging applications that convey presence awareness are quickly becoming some of the most popular groupware applications. They support lightweight and intermittent interactions that allow users to qiiickly move between a personal and a collective space, thus blurring the traditional distinction behveen synchronous and asynchronous systems. 'Often, however, the focus of collaboration is not another person, but a shared resource that is being produced in collaboration. Thus, rather than being interested in the presence and statirs of a collaborator, our main interest might be whether a given document is now mailable for one to read or review, or if such resource has changed since it was last visited. In this paper we describe DocZU, a system that provides presence awareness of resources stored in the Web. We describe use scenarios that motivated its development and its current implementation as an extended service of a Web server. The tool ,forms part of the services currently being developed to support collaborative authoring on the WWW under the PIflAS pla form. Keywords: Document presence, state notification, collaborative writing, DocZU, PISAS.

1. Introduction Currently, the World Wide Web environment provides support, mostly, for single-user browsing and authoring. In recent years, considerable efforts have been made to support collaboration over the Web through synchronous browsing [ 1 I], collaborative workspaces [ 1j, and casual interaction environments [2] among others. However, limited efforts have been made to support cooperative authoring on the Web. The main effort to support collaborative authoring on the Web is the WebDAV project [ 9 ] . It defines standard extensions to the HTTP protocol [7] to support property (metadata) management, locking, access control, and namespace management of resources in a centralized

0-7695-1351-1/01 $10.00 0 2001 IEEE

server. More recently, the PIfiAS project [5] proposes a middleware to provide similar services in a replicated architecture that results in increased document availability, thus allowing for distributed and nomadic cooperative authoring on the Web. Both projects have in common that they provide mechanisms for robust document management in Web servers. However, collaborative authoring requires additional support for the coordination and allocation of the authoring activity, as well as flexibility to support the dynamically changing needs of the collaborative writing group over time [ 10, 13, 301. The coordination of the authoring activity includes the need to support several writing strategies, to communicate changes among co-authors, to provide author information that allows users to infer the consequences of the changes and their impact in the collaborative activity, as well as to provide collaborators with information related to the current state of the authoring process. The flexibility requirements include the need for simple methods to support seamless transitions among writing strategies (sequential, reciprocal, and parallel) [20j, among writing activities (brainstorm, research, initial plan, write, edit, review) [IS], between synchronous or asynchronous ways of communication [ 131, and from a private to a shared workspace [ 141. To address some of these issues, we introduce the concept of document presence information, so that document reference entities could be registered into Instant Messaging and Presence (IM&P) systems. That is, documents will have first class presence in the IM&P system, and users could subscribe to them to be notified of changes in their status. Furthermore, users will be able to interact with these documents in a similar fashion as they interact with their colleagues. The server where the document is stored will manage the document's presence entity, so that, whenever the server detects an operation that changes the document status, it will noti@ the IM&P system, which in turn will noti@ all subscribed users. This kind of information can be used by co-authors to coordinate their collaborative efforts.

125

Internet IM&P services such as ICQ. AOL Instant Messanger, Microsoft Messanger, and Yahoo Messanger, have become surprisingly popular mostly because of their ability to provide a simple mechanism to let users: 1) “instantly” know the status of other users (online or offline) and changes to their status (available for chat, out to lunch, busy, etc.), 2 ) sendireceive synchronous or asynchronous messages toiftom them in an effortless manner and 3) launch additional applications to interact with them (chat, audio, and video conferencing, etc.) [SI. Additionally, the recent availability of such services on handhelds and cellular phones is very appealing as evidenced by the surprising success of NTT DoCoMo’s imode in Japan [ 121. This kind of groupware applications supports lightweight and intermittent interactions allowing users to quickly move between a personal and a collective space, seamlessly moving between synchronous and asynchronous interaction. Often, however, the focus of collaboration is not only another person, but also a shared resource that is being produced in a cooperative fashion, and rather than being interested in the presence and status of the collaborators, our main interest might be whether the given resource is now available for one to see or modify, or if such resource has changed since it was last visited. To illustrate this need, consider the following hypothetical scenarios: 1) Bill has just finished the final drafr of his thesis. He now has to give it to his advisor, Helen, and wait for her to review it. She is quite busy and might take several days to review the document. Bill doesn’t want to pressure her but wants to be notified as soon as the revision is over so that he can start incorporating the changes. Furthermore, he would rea& like to be notified while his thesis is being reviewed so that he can be present to more easily comprehend his advisors comments and criticisms. 2 ) As assistant editor for an academic journal, Laura, edits and reviews the articles that will appear in each issue to correct style and adhere them to the journal’s editorial guidelines. To protect the technical accuracy of the articles, she works with the authors in a collaborative editing process. As the deadline for sending the journal to print nears, being informed of the arrival of the authors’ latest versions and comments becomes critical, so that she can give the finishing touches to the articles and send them to press. 3 ) Alex is co-authoring a research paper with a couple of colleagues and he needs to incorporate his final contributions and send the paper today. However, the latest version of the paper is currently locked by one of his co-authors who has left town to attend a conference for the week.

These scenarios highlight the need for mechanisms to notify users in a collaborative environment of changes to resources and their properties in a timely manner. Until now, this need has been partially fulfilled by e-mail, perhaps due to its ubiquity, and/or due to the lack of a better solution. However, this solution requires explicit actions from the user who might not be aware of the needs of others. In this paper we describe Doc2U, a system that provides presence awareness of resources stored in the Web by integrating two ubiquitous technologies: The WWW (and some of its extensions) and IM&P services. It extends traditional IM&P systems by including document presence information for session management, document awareness, and collaboration support. We describe the development of Doc2U and its current implementation as an extended service of a Web server. The tool forms part of the session management services currently being developed to support collaborative authoring on the WWW under the PIRAS platform [ 5 ] .

2. Document presence information The concepts of presence information of users and resources have been used implicitly and explicitly for several years in collaborative systems, examples of these include the work on session management in Rendezvous [ 161; the concept of session management based on user activities, and the use of a publisWsubscribe model to disseminate this information in Intermezzo [6]; the user awareness protocol that records the presence o f users on Web pages [15]; the use of rooms with persistent documents and tools in TeamRooms (Groupkit) [ 191; and the Notification Servers and NSTP to maintain and communicate a centralized shared state of “things” in “places” [ 171. Although Cohen et al. (2000) have used the term “document awareness”; it refers to the awareness of “users” being at the “same instan[” on a “chut room or Web page”, not to the presence of the document itself. In the present work, we take an approach to document presence information centered on the relation of users to documents, i.e. based on the current state of the document in terms of the collaborative activities of the users involved in the creation, modification and/or use of it. As a first step towards determining the concept of document presence information, we established an analogy with the concept of user presence as used by IM&P systems. The motivation for this approach is the remarkable success of this kind of systems that utilize user presence information to manage a session, and to maintaidpromote collaboration using a space-based approach.

126

2.1. The User - Document presence analogy Table I compares the concept of user presence and the fimctionality of traditional IM&P systems with the concept and fimctionality of a system that provides document presence awareness. This comparison is made in terms of information like: status, availability, and user activityhteraction. For instance, while a traditional IM&P system reports user presence with a status such as online or away, for documents, their status information might be reported as free for access or locked.

Table 1. Analogy between the concept of user presence

information associated to a document changes, users can be notified of it, since this could modify the way they work on the document, or enable them to collaborate among them.

2.2. States and events of document presence Relevant document states, and the events that produce such states can be classified as related to availability, user activity/interaction, content, and meta-information. Figure 1 depicts the state diagram for these document presence states and events.

in IM&P systems and document presence.

availabk lock()

I Registered Not registered Status and Availability

User activity / interaction

Available (online) Unavailable (offline) Normal online Available for chat Away Extended away Do not disturb Reading Annotating Writing Request for subscription Send message to user Launch application to communicate with user (chat, audiohide0 conference, etc.)

,.d'

1

locked reservation( ) /resv++ reservalion() /res"++ A

Registered Not registered

Available (online) Unavailable (offline) Idle (free for access) Partially available Locked Locked and Reserved Being read Being annotated Being written Request for subscription Send command to document Launch application to work on document (edit, annotate or browse, etc.)

Another kind of information that is of interest to establish the concept of document presence, and important when considering session management and awareness in collaborative environments, is the result of user and system activities on documents. This information includes: changes on content related information, and meta-information related information. Content related information. As users create, use, and modify documents, new versions of them are required and generated. Whenever a new version is available, interested users can be notified of the change. Online users will receive the notification almost immediately; offline users will be notified of the change as soon as they login into the system. Meta-information related information. Users that interact with documents can change not only the content of the document, but also, the meta-information associated to them. This kind of information could be used to control and facilitate collaborative efforts. Whenever the meta-

Figure 1. Document presence state diagram. This diagram shows that concurrent states for a document are possible, this because presence information can represent the logical state of the document in storage (availability-related) and its logical state as utilized by coauthors (user activityhnteraction-related). A listing of the states and events of the diagram follows. For the sake of simplicity, some states and events are considered special cases of others. Availability-related states. Regarding availability, the document can be Available, (temporally or permanently) Unavailable, Locked, Unlocked, Reserved for lock, or Unreserved for lock. Availubility-related events. Corresponding events are Add or Restore, Remove, Lock, Unlock, Lock Reservation, and Remove Lock Reservation.

127

User uctivity/interuction-reluted states. With respect to user activityiinteraction, the document can be Zdle, In Use, Being Read, Being Annotated (special case that also includes the possibility of other authors reading the document), or Being Written (special case that also includes the possibility of other authors reading, or annotating the document). User uctivity/interuction-reluted events. In this case the events are Add or Release, Use, Read, Annotate, or Write. Additionally, multiple state representations for a document are required due to the fact that for each user, a unique representation of the state is possible. This means that a particular document could be new for one user, but recent or old for other users, thus, a client management representation is needed. One way to achieve this is by means of a document proxy on the client side.

y ;;d ;

[temp >threshold]

updated

update( )

Figure 2. Additional document presence state diagram.

and chat conferences), Doc2U provides document presence information for session management (implicitly creating, joining, and leaving a session based on shared artifacts and activities [6]), document presence awareness (document status and availability, as well as userdocument activity and interaction), and collaboration support (for coordination and communication using the metaphor of a shared virtual place with shared artifacts [19]). To extend the traditional user presence concept used by IM&P systems, Doc2U includes document presence information based on the state and events identified in the previous section. The presence information (status) of documents and users is notified to subscribed users whenever this information changes.

3.1. Doc2U architecture The Doc2U architecture is based on the client-server model. As illustrated in Figure 3, there are paired component-server elements at each layer; the fbnction of each component in the client side is to give access to the services that their server side counterpart provides, as well as to provide specific client side behavior (e.g. document proxy). There are three different kinds of paired components: user management component and server, document management component and server, and session management component and server.

As indicated in Figure 2, these additional states and events are the following: Confent reluted stules. Regarding content, a document can be New or Updated, Recent or Old. Content reluted events. The corresponding events are Update, Read, and an automatic event guarded by the condition [time > threshold] with threshold determined by the user. Metu-information reluted events. Finally, metainformation related events depend on the kind of metainformation associated to the document. The state of the document could or not be affected (see the example below); the event and the change of state (if any) should be notified to interested users accordingly. Examples of this kind of events are: Add user (a new user (author) has been added) and Remove user (a user (author) has been deleted).

Client Application Layer (CAL) User Applications User management component

A

Session management component

pFl 4

User management server

Session management server

Client Layer

Document management component A

I

Document management server

Server layer

(PMC) PresenceManagementCamponent (PMS)PresenceManagementServer

Figure 3. Doc2U client-server architecture.

3. Doc2U: A document presence notification service Doc2U is a Document to User event notification service that forms part of the session management model of the PIN AS platform. Besides supporting the traditional IM&P system features for synchronous and asynchronous collaboration (user presence awareness, instant messaging,

Each component-server pair provides specific services to user applications running on top of them. A description of them follows: User (author) management component and server: Store user’s profiles, and provide authentication based on specific user information (login name, password), this

128

allows for dynamic userlsite management (mobility of users and clients), desirable for nomadic support. Document management component and server: Handle document versioning, document merging, and document distribution/replication, among other document specific features. Session management component and server: Maintain project and session information (i.e. which users, with which rights, on which documents, user and document presence status, user localization, etc.) for client access. The User management and Document management services for PIfiAS have been described elsewhere [5], therefore, herein we only describe the session management component and server. The session management server implements two types of entities: projects and sessions. A project is the “longterm” definition of the collaborative effort in terms of the relation document-user; it functions as a template to build default sessions, each of which could be customized to fulfill particular run-time collaborative requirements. A session is the representation of an ongoing instance of the collaboration, and maintains the “current” status of each element involved based on the document-user relation. The information that should be specified in a project includes: Documents that will be involved in the collaboration. These documents must be registered in the document management service, and references to them should be registered in the presence service of the session manager. These references will be used during a session to track changes in their state, which will be notified to interested parties. Users that collaborate in the document creation process. These users must be registered in the user management service, and references to them should be registered in the presence service of the session manager. As with documents, these references will be used to track and notify changes to interested parties. User permissions and roles. These permissions define the types of operations that a user is allowed to make on a document; these permissions could be used to define potential user’s roles. On the other hand, the information that is maintained in a session is the one that “dynamically” changes while users work on documents, and the way this activity changes their state. This information includes: Status of participants and resources from the point of view of availability. Status of participants and resources from the point of view of activity. In this case, users are interested in the status of another collaborator, and the status of resources based on user’s activity. Status of resources from the point of view of content and/or meta-information modrfication. In this case, users

are interested in knowing when changes on content and meta-information of resources are made. Finally, in order to obtain and notify these events that represent the “current” state, the session management service includes a presence management componentserver pair, depicted in Figure 3 as PMC and PMS respectively. The presence management component (PMC) is in charge of detecting the events that change the state of users and resources, and notifying these changes to the presence management server (PMS). The presence management server is in charge of receiving events, maintaining state, and notifying changes coming from specific clients, as well as forwarding these events to specific interested parties. An important characteristic of this approach is that the user management server and the resource (document) management servers are also clients of the presence service. This is due to the need to “detect and notify” changes on the presence of the entities they manage, as opposed to traditional IM&P systems, where presence clients are only used on the user-application side, because they only work on user presence information. For implementation purposes, the presence management components can be hard-coded into clients or servers, or could exist as external services available to clients and servers. There are advantages and disadvantages to both options. The main advantage of having the components hard-coded is the tight functional integration and level of granularity that can be achieved regarding event notification. However, this approach is very intrusive from the development point of view and considerable changes are required for the applications to be used. On the other hand, having the components as external services allows the use of common-of-the-shelf tools, with the added value of having a priori the user’s expertise on their utilization, and that only a single component (the presence client) needs to be added and learned to use. Also, this single component could be executed as a separate lightweight application without having to utilize other heavier applications, such as a Web browser or a collaborative word processor, to receive and send user and resource presence status information. The main disadvantage in this case is that the level of integration among the tools and that the granularity of the events is low. However, for the present architecture these two approaches are not mutually exclusive, and a combination of them could be used. Finally, by allowing the user and document management servers to be clients of the session management presence service, all the changes introduced are transparent to the users, regardless of the type of applications that they use (with the required system components hard-coded into them or not). Also, this feature can be added to any resource server in the groupware domain (or any other) that could generate events that are of interest to subscribed users.

129

3.2. Current implementation The current implementation of Doc2U uses commonoff-the-shelf components; some of them extended to support document presence more efficiently. The Doc2U session client is the document and user presence viewer; it allows a user to receive notification of changes on the state of the documents and users he/she is subscribed to, as well as to interact with them by sending them commands or messages respectively. It is implemented using the JabberCom library. Jabber (http://www.jabber.org) is an open source IM&P system that consists of the Jabber presence protocol, the IM&P Server, the JabberCom client library, and the JabberHTTPServlets among other components. Jabber was chosen as the IM&P service because it is based on XML, manages a distributed network of clients and servers, its presence protocol and the code are open source, and it has a modular and extensible architecture. To create and manage projects we developed Collaborative Project helper Tool (CollabProjTool). It is used to specify which users participate, working on which document, and with which rights. The basic operations include: add documents and its authors. upload newer versions of documents, modify author rights, request and release document locks. It runs on a form-capable Web browser. These two basic components, along with several resource creation tools (text, graphic, and binary files) have been used for the co-authoring of this article. The document storage server is implemented as an extended Apache HTTP Web server. The first extension to the HTTP server is an ensemble of servlets that implement a set of WebDAV-like operations (get, put, delete, lock, and unlock) [9], as well as the Jabber client interface. To allow the use of the servlets within the HTTP server, a Tomcat type 2 servlet container (http://jakarta.apache.org/tomcat) is used. The server-side Jabber client interface is based on the JabberHTTPServlets. Also, an IM&P Jabber Server is used as an out-of-thebox session and user server, this is possible because the server doesn't require to semantically interpret the presence information of an entity, i.e., for the server all these entities are of the same type. The differentiation, however, is made on the client side, because the client requires distinguishing among the different kinds of entities involved (currently users and documents). Figure 4 depicts the implementation architecture described above.

3.3. The system in use To illustrate Doc2U in use, we will describe its application in the first scenario presented in section I , in

which a student (Bill) waits for his advisor (Helen) to review the latest version of his thesis. Once he has finished the latest version of the document, Bill uses the CollabProjTool client to upload it to the document repository, as shown in Figure 5 . Client Application Layer (CAL)

1)lrXJ

1 dllclr

Client Layer

*.p.

&*.a

I .dl(a

Session

Session and User Management

Doc management Server

Server layer

>\Dache Scwcr Tomcat Srrvlei Coniaincr

JabberHTTPServlcis

I

I

I

I

Figure 4. Current implementation architecture.

*othon:

Damnatr:

Figure 5. A document is added to t h e shared document repository using CollabProjTool.

After the document is successfully uploaded, the system notifies Helen and Bill of this event generating a document subscription request for both of them. They will receive this message in their Doc2U clients. Figure 6 shows Helen's Doc2U client when she receives such request (6a) and accepts it (6b). Helen could choose to decline the request if she is not interested in monitoring changes in the state of the document. This request message is similar to the one that a user of an IM&P system will receive when another user wants to add him/her into hidher contact list. When Helen starts working on the document, by locking and downloading it for edition, these events are notified by the system to Bill by changing the icons to the

130

left of the document’s name as shown in Figure 7a. When Bill notices this change he can decide to join Helen in a synchronous collaborative review session by sending her a request through the document, or he can wait for her revision to be finished - as indicated by the new document status (new version and unlocked) in Figure 7b - to start incorporating the changes (asynchronous collaboration).

obtain the most up to date version of the document, incorporate his final contributions and send the paper on time.

IbI

Figure 7. Bill’s Doc2U client showing the document locked and Being-Written (a) and a new version and unlocked (b).

4. Related work

Figure 6. a) The notification of a Document Subscription Request as presented by Doc2U to user Helen. b) Helen’s Doc2U client showing the recently added document marked a s new. In support for scenario number 2, Laura must create a project with CollabProjTool for each author she works with and add the article’s documents. Then each author could upload new versions of hisher documents in their own private project space, and Laura’s Doc2U client will notify her when new versions of the documents are available. In this way, notifications of new versions will be “an instant message away”. For scenario number 3, we could assume that a Doc2U client in a handheld is available for the co-author who has locked the document and is away in a conference. Thus he can be notified when his co-author requests the document without needing to be at his desktop. Also, by means of this Doc2U client, he can release the lock on the document, and his co-author will be notified of this in his Doc2U client. Upon receiving the notification, Alex will

The approach to track shared resources presented here is inspired by instant messaging or user presence awareness applications such as ICQ, AOL Instant Messenger, and MS Messanger. This type of application has become increasingly popular in the last few years and client applications have been developed for handheld computers and the new generation of cellular phones. Instant messaging systems however, only provide awareness on the state and availability of other people. For this reason, even when a traditional IM&P application can be used as a “companion tool” to provide or complement the collaborative features of the other application, it will still lack the ability to provide document presence awareness information. Kirby and Rodden [ l o ] identify the need for lightweight monitoring of shared resources during collaborative authoring. The Contact toolkit they developed, uses Watch Objects to detect alterations to files or register commands invoked upon files. Contact also resembles Doc2U in pursuing the goal of supporting multiple platforms and tools that collaborators might use when working with documents. However, rather than using a non-intrusive interface to monitor activities on documents, users need to explicitly consult the state of a particular document using a Web browser. In contrast, users of Doc2U can track the state of several objects and collaborators with a simple glance. The Notification Service Transfer Protocol (NSTP) was proposed to share state information among a set of clients that work together in a synchronous multi-user application [17]. As a service for synchronous

131

applications, the designers of NSTP placed special concern in its efficiency. As noted by its authors, NSTP provides similar functionality to that offered by session managers of other synchronous groupware toolkits. NSTP however, does not support persistent state required in asynchronous groupware, as is the case of collaborative writing. The BSCW system is a Web-based shared workspace that recently incorporated an event service to notify users when certain actions, such as uploading or renaming a document, occur [ 11. The events are notified via email or using a monitor applet. Through the latter, a user can monitor who is currently working with the BSCW server, be notified of events or activities performed by these users, and launch a chat session with an active user. In contrast with Doc2U the event service in BSCW is user centric rather than being focused on the document. Users of the system track activities of other users connected at the same time to the BSCW server, if the user is only interested on whether a document is being read or has changed, he/she needs to filter this information from the monitor that lists all user actions. Furthermore, this information will not be available when the other users are working in disconnected mode. Systems such as I21 [2] and Centers [4] provide awareness of other people accessing a particular Web page at the same time, thus facilitating collaborative browsing or informal encounters among them. To know who else is currently looking at a given page a user is required to access the Web page, thus this approach provides poor support for asynchronous collaboration. Additionally, changes in document content cannot be notified to interested users. Finally, there are systems such as MindIT (http://mindit.netmind.com) that track changes in Web documents and inform registered users of these changes by sending them email. These systems are meant for monitoring infrequent changes in documents and provide poor support in co-authoring activities. The fact that change notification is done via e-mail is opposed to Doc2U requirement for lightweight continuous presence awareness.

5. Conclusions and future work The unexpected success of IM&P applications, which quietly hide in the background, give its users a window to people they want to keep in contact with. Similar services might be useful for the creation and management of shared resources, as well as for the coordination of their co-authors’ activities. This paper introduces the concept of document presence as an analogy of user presence as implemented in IM&P systems. Users can be subscribed to the presence of

documents and be notified of changes in their status. The notification of these events is used to coordinate the activities of co-authors, to initiatehaintain collaborative sessions, and to allow seamless transitions between synchronous and asynchronous modes of work. Also, by means of document presence, users can interact with the documents using lightweight interfaces. As part of the development of the PIRAS infrastructure to support collaborative writing on the Web, we have designed and developed Doc2U, a presence awareness system that implements a document notification service. In addition to standard features of traditional IM&P systems, a Doc2U client allows users to be subscribed to documents they want to keep track of, monitor changes in their state, and send messages to request a lock or launch an application to modify them. Finally, we plan to upgrade the current centralized Doc2U architecture to support PIRAS’S replicated document storage services, thus increasing availability as required in a large-scale distributed co-authoring environment on the WWW.

Acknowledgements This work was supported by ECOS and ANUIES (project M98-01) and by SEP-SESIC and UABC (grant P/PROMEP:UABC-2000-08), with the scholarship UABC-125 provided to the first author. Additional financial support was provided by CONACYT under grant 29729A.

References [ I ] Appelt, W.: “WWW Based Collaboration with the BSCW System” in proceedings of SOFSEM’99, Springer Lecture Notes in Computer Sciences 1725, Milovy (Czech Republic): Nov 2 6 Dic 4 1999, pp. 66-78.

[2] Budzik J.: X . Fu: and K. J. Hammond, “Facilitating Opportunistic Communication by Tracking the Documents People Use“, ACM CSCW’2000 Workshop on Awareness and the WWW: http://www2.mic.atr.co.jp/dept2/awareness, 2000. [3] Cohen, D.: M. Jacovi, Y. Maarek, and V. Soroka, “Collection Awareness on the Web via LiveMaps“, ACM CSCW’2000 Workshop on Awareness and the WWW, http:/lwww2.mic.atr,co.jp/dept2/awareness, 2000. [4] Contreras: J.: C. Perez, and J. Favela, “Informal lnteraction

in Online Teaching and Learning“: to appear in proceedings of ED-MEDIA 2001 World Conference on Educational Multimedia, Hypermedia & Telecommunications, Tampere, Finland: June 2001. [ 5 ] Decouchant, D.:J. Favela, and A. M. Martinez, “PfiAS: A Middleware for Web Distributed Cooperative Authoring“, in proceedings of The 2001 Symposium on Applications and the

132

Internet (SAINT’2001), San Diego, CA, USA: 8-12 January 2001: pp. 187-194.

[6] Edwards. W. K.. “Session Management for Collaborative Applications”. in proceedings of ACM CSCW’94. ACM Press. Chapel Hill. NC. USA. October 1994. pp. 323-330. [7] Fielding. R.. J. Gettys. J. Mogul. H. Frystyk. and T. BernersLee. “Hypertext Transfer Protocol - HTTP/I. I-’. RFC 2068. Jan 1997. [SI Godefroid. P.. J. D. Herbsleb, L. J. Jagadeesan, and D. Li: 2000. “Ensuring Privacy in Presence Awareness Systems: An Automated Verification Approach”, in proceedings of ACM CSCW’OO. ACM Press, Philadelphia, PE. USA, December 2000. pp. 59-68.

[9] Golang. Y. Y.. E. J. Whitehead. Jr.. A. Faisy. S. R. Carter. and D. Jensen. “HTTP Extensions for Distributed Authoring WebDAV”. RFC 2518. Feb 1999. [ I O ] Kirby. A.. and T. Rodden. “Contact: Support for Distributed Cooperative Writing” in proceedings of ECSCW’95. Stockolm. Sewden. Sep IO- 14 1995. pp. I O 1 - 1 16.

Kobayashi. M.. M. Shinozadi: and T. Sakairi. “Collaborative Customer Services Using Synchronous Web Browser Sharing”. in proceedings of ACM CSCW’98. ACM Press. Seattle, WA. USA. November 1998, pp. 99-108. [Ill

[I21 Mitsuoka M.. S. Watanabe. J. Kakuta. and S. Okuyama. “Instant Messaging with Mobile Phones to Support Awareness”, in proceedings of The 2001 Symposium on Applications and the Internet (SAINT’2001). San Diego, CA. USA: 8-12 January 2001. pp. 223-230. [I31 Neuwirth. C. M.. D. S. Kaufer. R. Chandhok: and J. H. Morris. ”Computer Support for Distributed Collaborative

Writing: Defining Parameters of Interaction”, in proceedings of ACM CSCW’94, ACM Press, Chapel Hill, NC: USA, October 1994: pp. 145-152. [I41 Newman, R.: and J. Newman, “Social Writing: Premises and Practices in Computerized Contexts”, in M. Sharples (Ed.): “Computer Supported Collaborative Writing”: Springer-Verlag, London, England, 1993, pp. 29-40. [U] Palfreyman, K.: and T. Rodden, “A Protocol for User awareness on the World Wide Web” in proceedings of ACM CSCW‘96: ACM Press Cambridge, MA, USA: October 1996, pp. 130-139. [ 161 Patterson, J. F.: R. D. Hill. and S. L. Rohall, “Rendezvous: An Architecture for Synchronous Multi-User Applications” in proceedings of CSCW’90, ACM Press, Los Angeles: CA: USA: October. 1990. pp. 317-328.

[I71 Patterson. J. F.: M. Day, and J. Kucan, “Notification Servers for Synchronous Groupware” in proceedings of CSCW‘96, ACM Press. Cambridge, MA, USA: October 1996, pp. 122-129. [IS] Posner. 1. R . and R. M. Baecker. “How People Write Together”. in proceedings of the 25Ih Hawaii International Conference on System Sciences. Vol. 4. Hawaii. USA. 1999. pp. 127-138. [ 191 Roseman. M.. and S. Greenberg. “TeamRooms: Network Places for Collaboration”. in proceedings of CSCW‘96. ACM Press. Cambridge. MA. USA. October 1996. pp. 325-333. [20] Sharples, M.. J . S. Goodlet. E. E. Beck, C. C. Wood, S. M. Easterbrook. and L. Plowman, “Research Issues in the Study of Computer Supported Collaborative Writing” in M. Sharples (Ed.). “Computer Supported Collaborative Writing“, SpringerVerlag. London, England. 1993, pp. 9-28.

133