X window based group collaborative editing system

X window based group collaborative editing system

X Window based group collaborative editing system W-Y Leu and S-M Yuan Group collaborative editing is an activity by which people geographically disp...

3MB Sizes 0 Downloads 123 Views

X Window based group collaborative editing system W-Y Leu and S-M Yuan

Group collaborative editing is an activity by which people geographically dispersed can edit the same document simultaneously. It makes use of computers and network communication to provide an interactive and convenient environment, so people can save much of their time and cost. We have developed a group collaborative editing system which not only allows participants to jointly view and process multimedia documents but also provides real-time interactive conversation facilities to let users feel realistic and friendly. This paper describes the concepts of group collaboration and the mechanisms of our system, h also presents the interface design strategy and the synchronization control method. groupware, networking, X-based systems, collaborative editing, real-time conferencing

The computers were initially designed for a single user to run a single job at a time, and much of the operating system design is concerned with isolating users from the potentially harmful effects of one another. Direct communication among users is typically through computer mail or 'talk' programs. Indirect communication occurs through changes in databases and files. Although talk programs provide better real-time interaction between two users, only recently has much work been done to bring users together as groups. Group activity dominates much of the modern workplace. The activity may be product development, scientific research, document preparation, administration, and/or entertainment. In fact, many of the most common multiuser programs available are games. Others can be found in the area of computer-supported cooperative works ~'2. For instance, in real-time computer conferencing 3-5, the users, who are often at different locations, communicate through a software medium. This software might allow the users to view and modify a shared graph structure or edit a shared outline. A typical scenario for producing a joint document is to call a meeting in which the outline of the document is produced and each part of the document is assigned to one of the team members. Next, the team members work in parallel, but in isolated situation, to produce the parts for which they are responsible. These parts are then assembled into a complete draft, which is passed via electronic mail (or by location in a shared directory) from one person to another for serial editing of the latest draft. At the last Department of Computer and InformationScience, National Chiao Tung University, Hsinchu, Taiwan 300, Republic of China Vol 35 No 11/12 November/December 1993

stage, serialization can produce many problems, as the person having edit rights to the latest draft essentially owns a lock on the entire paper. This forces others to wait, often until a less convenient time for them and often under deadline pressures. Coordination is often a problem, as the group must repeatedly decide who should next edit the latest draft. A real-time groupware software would eliminate these problems. An example of real-time groupware is our system, MGEAT (Multimedia Group Editing And Transfer), a prototype of group collaborative editing system. It is intended for use by a group of people simultaneously working on text, image, voice, graphics, and hand-drawing documents. Its facilities include the participants' invitation, multimedia document group editors, multimedia file transfer, textual message interchange, on-line multiway talk and the verbal spoken subsystem. The group members could not only edit various media of documents but also discuss in textual or verbal type depending upon convenience and efficiency. In this paper, we present the concept of the term groupware design issues and features, and the implementation of our system. Finally, some conclusions and future works are described. GROUPWARE


Society acquires much of its character from the ways in which people interact. Although the computer in the home or office is now commonplace, the interactions between people are more or less the same way as they were a decade ago. As the technologies of computers and other forms of electronic communication continue to grow, however, people will continue to interact in new and different ways. One probable outcome of this technological marriage is the electronic workplace--an organization-wide system that integrates information processing and communication activities. The study of such systems is part of a new multidisciplinary field: Computer-Supported Cooperative Work (CSCW). Drawing on the expertise and collaboration of many specialists, including social scientists and computer scientists, CSCW looks at how groups work and seeks to discover how technology can help them to work. The term 'groupware' is frequently used almost synonymously with CSCW technology. Groupware is viewed as the class of applications, for small groups and for organizations, arising from the merging of computers and large information bases and communications technologies. In this


© 1993 Butterworth-Heinemann Ltd


X Window based group collaborative editing system paper, we first describe the definition of groupware in terms of a group's common task and its need for a shared environment; then we provide a taxonomy of groupware systems. After that we describe the widely ranging perspectives of those who build these systems. Finally, we introduce some common groupware concepts. Most software systems support only the interaction between a user and the system. Whether preparing a document, querying a database, or even playing a video game, the users interact solely with the computer. But in systems designed for multiuser applications, some supports for user-to-user interactions are required. Computer-based or computer-mediated communications, such as electronic mail, are not fully integrated with other forms of communications. The primarily asynchronous, text-based world of electronic mail and bulletin boards exists separately from the synchronous world of telephone and face-to-face conversations. Similar to communication, collaboration is a cornerstone of group activity. Effective collaboration demands that people share information. Unfortunately, current information systems--database systems in particular--make great efforts to insulate users from each other. They are seldom able to modify different parts of the same object simultaneously and be aware of each other's changes; rather, they must check the object in and out and tell each other what they have done. Many tasks require an even finer granularity of sharing. What is needed are shared environments that unobtrusively offer up-to-date group context and explicit notifications of each user's actions when appropriate. Real-time groupware systems are characterized by the following6: • highly interactive--response times must be short • real-time--notification times must be comparable to response times • distributed--in general, one cannot assume that the participants are all connected to the same machine or even to the same local area network • volatile--participants are free to come and go during a session • focused--during a session there is high degree of access conflicts as participants work on and modify the same data • external channels--often participants are connected by external channels such as audio and/or video links

and wanted to architect the system's features carefully, along with its look and feel. MGEAT was chosen to minimize the functionality and coding time spent on the standard editing features and to concentrate on its groupware features. These features include the private and shared text group windows, shared graphic window, and shared hand-drawing window. The architecture allows finegrained concurrent editing and notification. In addition, MGEAT provides a verbal spoken subsystem to let participants discuss in real time, and a multimedia file transfer facility for participants interchanging their files. The MGEAT diagram is shown in Figure 1. The architecture uses a local editor, replicated documents at each user's workstation, and a centralized coordinator that serializes the operations of the various editors.

Design issue One approach to construct group interfaces is known as WYSIWIS 7. This acronym stands for 'What You See Is What I See' and denotes interfaces in which the shared context is guaranteed to appear in the same way for all participants. The advantages of WYSIWIS are a strong sense of shared context and simple implementation. Its major disadvantage is that it is inflexible. Experiences have shown that users often want independent control over such details as window placement and size, and may require customized information within the window. We use the policy WYSIWIMS (What You See Is What I May See), a relaxed WYSIWIS model. In MGEAT system, participants can scroll, resize, and place their shared editor window. Although the context of the group shared windows is the same, users can operate their own window according to their mind. One participant's action does not affect others' shared window except updating. A good group interface should depict overall group activities and not be overly distracted. For example, when one user locks or updates a segment in the text editor, other users do not know what happens. This points up a fundamental difference between singleuser and multiuser interfaces. With single-user interfaces, users usually have the mental context to interpret any display changes that result from their actions. As a result, the sudden disappearance of text at the touch of a button is acceptable. By contrast, with group interfaces, users are generally not aware of others' contexts and can less easily

SYSTEM DESIGN ISSUES The Multimedia Group Editing And Transfer (MGEAT) is a prototype of real-time groupware that illustrates some of the concepts just introduced. MGEAT is an editing system, including text, graphic, and hand-drawing, designed for a group of people to edit the same document in a work session simultaneously. MGEAT was built from scratch rather than beginning with the code of existing editors, because we wanted to understand, control, and modularize the code in particular ways. We were especially concerned with the user interface, 640

Figure 1. MGEAT functional diagram Information and Software Technology


interpret sudden display changes resulting from others' actions. What is needed are ways to provide contextual clues to the group activities. The solution of MGEAT is that there is a pair of special symbols 'q' and 'qq' to mark the lock area of every participant's shared text window when someone applies lock action. 'q' means the beginning of the lock area and the 'qq' means the end. Therefore, the system will decrease the lock collision. For update actions, the system also lets the last updated text segment be marked by underlines, so users can see the last change. In fact, all updated text segments should be marked, so users can know which portions of the document having been updated. But it cannot be done due to the restriction of the XView toolkit, which has only two selection marks. It cannot get more than two selection marks simultaneously. Besides, the system will inform users who do the action too. The example is shown in Figure 2.

Concurrency control Groupware systems need concurrency control to resolve conflicts between participants' simultaneous operations. With a group editor such as MGEAT, for example, one person might delete a sentence while a second person inserts a word into the sentence. Groupware presents a unique set of concurrency problems 8-1°, and many of the approaches to handle concurrency in database applications-such as explicit locking or transaction processing cannot be applied here directly. The following lists some of the concurrency related issues ~l.

Responsiveness. Two properties are required. A short response time which is the time required for a user's own interface to reflect his or her actions, and a short notification time which is the time required for these actions to be propagated to other participants' interfaces. First response times are important--the time taken to access data, modify data, or notify users of changes must be as short as possible. Secondly, if the concurrency control scheme entails the use of others, then the effect of these modes on the group's dynamics must be considered and only allowed if they are not disruptive. Wide-area distribution. A primary benefit of groupware is that it allows people to work together, in real-time, even when separated by great physical distances. With current communication technology, transmission times and rates for wide-area networks tend to be slower than local area networks. This impact on response time must therefore be considered. In addition, communication failures are more likely to happen in wide-area network. This leads to the need for resilient concurrency control algorithms. Data replication. Because the response time demands for groupware systems is so high, the data are usually replicated for each participant. This allows many potentially expensive operations to be done locally. Typically, each participant would be working in a windowing environment. If the object being edited is not replicated then even simple scrolling operations require communication between the two sites. The resulting degradation in response time may be catastrophic. Robustness. Traditionally robustness refers to the recovery from unusual circumstances; typically these are component

Figure 2. The shared window for group focus Vol 35 No 11/12 November/December 1993


X Window based group collaborative editing system

failures--the crash of a site or a communication link breakdown. While these are also concerns of groupware systems, there is also a second form of robustness to user actions. With groupware systems, the addition of a participant may lead to reconfigurate the system. Clearly the concurrency control algorithm must adapt to such reconfigurations and in general recover from 'unexpected' user actions (abruptly leaving the session, going away for coffee . . . ) . We now describe the concurrency control method used in the MGEAT system. In the text editor, the method is based on the locking, transaction, and central control. It considers the difficulty and the performance of the implementation and the features of groupware systems. A simple method, that locks data before it is updated, is used. When users want to update or delete a text area, they first select a continuous segment of the text, then perform their operations. The lock action is embedded in the update action. The information of the lock area, including the beginning, end, action and who locks the area, is sent to the coordinator. All the requests are handled centrally by a coordinator, who is usually the chair of the group editing session. The coordinator checks whether the current lock request has a collision with others or not. If not, delete action is executed or update private window appears in the requesting participant's screen. Otherwise, the lock failure message is shown to the lock requester. As previously mentioned, MGEAT uses a couple of special symbols to indicate locked area in order to decrease the likelihood of conflict requests for these areas. In MGEAT, real lock action and update actions are separated. Users can do the update operations only when they successfully lock a segment. In update phase, transaction mechanism is applied. During the update transaction, all lock requests are rejected, because the update transaction consists of the data update and the lock table (i.e. a table to record the users' lock information) update. If a new lock request arrives when central controller is doing the transaction, the information of the lock request will be out of date. The lock range positions are not the original ones. The data update is that the centralized controller send the update information to all the participants' shared window and wait for the finish of all of them. If an update request arrives when a previous update request is being executed, it will be put into the update-wait queue. When the previous update transaction finishes, the centralized controller continues to serve those waited updates until the queue is empty. In the text editor, every participant can only lock one area at a time. In the graphic and hand-drawing editors of MGEAT, all the actions are sent to the central controller and performed in every participants' related window. There is no lock mechanism needed for the editor, but it has an 'undo' operation to alleviate some of the problems mentioned above. All the update operations are serialized by the central controller. The advantages of our approach are: • simplicity--the method is direct and easily implemented • flexible--MGEAT separates the group shared window and private window to let users make use of all the


original text editor functions (e.g., load, clear, copy, cut, paste . . . . ) to edit the data they want to update • fine granularity--the granularity of update segment is dynamic from a single character to a whole file • privacy--users can edit the content privately; if they finish, they can push the 'complete' button to commit: the editing procedure is invisible to other users • lower traffic--the editing content is sent to all other team members when it is committed: the time of editing data transfer is decreased, so the network traffic can be low

IMPLEMENTATION The implementation platform of MGEAT was chosen on the criteria of availability, portability, extendibility, speed, and the ease of implementation. MGEAT is written in C, a language that can be exploited for speed of execution and portability. It is implemented on the UNIX operating system which has wide usage in academic and scientific circles. The user interface is built on the X Window System. We also apply XView toolkit and OpenWindow's Developer's Guide interface generator to design our user interface appearance. The choice of widgets as opposed to the Xlib saved the trouble of rewriting the low level menuing, window mapping, and event parsing routines. The following sections will describe how the system connections are established and the details of each function.

System connection establishment MGEAT is based on the chair-participants model. All the things about the session establishment are managed by the chair host, centrally. The system in each host consists of two processes: a daemon and a primary process to execute the system. A daemon process is running in each host's background. Its responsibility is to accept the invitation from the chair and inform participants. A primary process named 'mgeat' runs our system. There are four steps for a group collaborative editing session to be established. These are: (1) The chairperson executes the 'mgeat' program and uses the 'invite' function of MGEAT to invite the people with whom he wants to work. (2) When the daemon in an invitee's host receives the invitation message, it checks whether the user logsin or not. If the user does not login, it writes an invitation message to a file. Next time the user logsin he can read the file to know what happens. The message includes the login name and the hostname of the chairperson and the invitation time. If the user has been logining the host, then the daemon writes an invitation message into his screen to inform him to join the session. The informing actions are based on the UNIX socket because it is not sure whether the invitee is in the window environment. (3) When a participant receives the invitation message, he can execute 'mgeat hostname' command to join the session. (4) As soon as the chair process receives the response Information and Software Technology


message, it will send the related information, which may include the member list of the session, the document that is going to be edited, and other related information, to the participant. The connection is established when the four procedures are finished. Other invitees can obey the above steps to enter the session. The system connection is shown in Figure 3.

r.El I AN[)

'¢,-vl Y t ! A N

of the session and the coordination o f group editing. If the chairperson leaves, the function of group editor will not work (other functions are still effective). Thus, the system chooses a new participant as a secondary chairperson. When a primary chairperson leaves, the secondary one can replace him as a primary chairperson. At the same time, if other participants exist, it chooses a participant as the secondary chairperson. The method to choose a secondary chairperson is according to their order in the group session.

System disconnection Participants can leave the group editing session al any time. including the chairperson. The leaving message is broadcast to the other members. M G E A T uses a flag array to remember the status of every participant. These flag arrays are the same in every participant's host. If the entry of someone is set, the system will not send any information to that host. A chairperson process is an important role in the group editing session. It is responsible for the establishment

chair_ _ J

machine A


send information attach

machine B ¢



check login


Figure 3. The system connection diagram

Group editing Text editor The text editor is worked in group collaborative mode. The data synchronization control uses replicated copies and applies central lock management to prevent the editing processing from collisions and maintains the consistence of the replicated copies. The editor can let multiple users edit the same text document at the same time. Every host has a shared text editing window, whose coptent is the same for all participants. When a user wants to edit an area lupdate, insert, or delete), he must use the mouse to mark the region in the shared text window, and then the system will send the related information of lock area to the chair host. It it is successful and the editing action is update or insert, i~ pops up another private text editing window. The user can make use of the editing function XView provides to do update operations. If the action is delelion. ,hen il deletes the marked area immediately ()ther functions of the text editor include the toad and save of shared file and the font type. Also. XView itself provides a strong editing function embedded in the text window. Every update action consists of a lock aad an

Figure 4. The graphic editor Of MGEAT Vol 35 No 11/12 November/December 1993


X Window based group collaborative editing system update request. While performing an update action, the central controller cannot receive any other request; and other requests will be rejected. Thus the user must know when the next request ought to be sent after the previous request has been finished.

Graphic editor The graphic editor consists of a drawing panel, a shape box, a font box, and a colour palette. The editor is also worked in group collaborative mode. Every action in the drawing window is shown in others' window too. The shape box includes text, line, circle, rectangle, fill circle and fill rectangle. The font box lists many sorts of font type and size. The colour palette has 65 colours from which the user can choose. It also provides undo and redo functions. The effect of undo and redo is for all the group members, not just the individual. The figures in the drawing window can be saved and loaded later. The graphic editor in MGEAT is shown in Figure 4.

Other functions in MGEAT Multimedia file transfer This function is for transferring multimedia files, including text, image, voice, and graphics. The receiver can be specified and these files can be represented in the receivers' host screen directly. The medium to transfer file is based on the X property. Senders put the file data into the receivers' property and then make use of ClientMessageEvent to inform receivers to get the file data and show them. The function is shown in Figure 6. Message transfer This function is an on-line textual message which can be sent to selected receivers. The primary purpose of the function is to let participants exchange messages privately. This function in MGEAT is shown in Figure 7.

Multiway text-based talk Hand-drawing editor Like the graphic editor, the hand-drawing editor is worked in group collaborative model too. It also provides a colour palette. Users can use the function to draw freely by their hands. The point size and the point colour are changeable. The editor also provides an eraser to correct the drawn figure. The interface of the function is shown in Figure 5.

This is a real-time text-based interactive talk facility. All group members can discuss in text mode. The content of the discussion can be saved. A user types in a sentence and then presses the (Enter) key to broadcast it. This function is shown in Figure 8.

Real-time spoken subsystem This function is activated automatically when a participant




Figure 5. The hand-drawing editor of MGEAT 644

Information and Software Technology

"~r-Y L E U

A N D S - M '~ U A N

Figure 6. The multimedia file transfer of MGEAT enters the group editing session. It lets the users discuss verbally in real-time by use of the Sun workstation audio device and the microphone. The voice of the users is recorded and played per second. The transfer of the voice is also through the X property. When some voice file is played or the voice editor is busy, the spoken conversation function is pause. It resumes after the related voice work is finished. This function increases the realistic, convenience and efficiency of the group work.

CONCLUSIONS Group collaborative editing system is a groupware by which people geographically dispersed can edit the same file simultaneously. It makes use of computers and network

Figure 7. The message transfer function of MGEAT communication facilities to provide an interactive and convenient environment, so people can save much of their time and cost. This paper has shown the conceptual underpinning of groupware--the merging of computer and communications technology. It has explored the technical problems associated with designing and building groupware system, and shown how groupware casts a new light on some traditional computer science issues. Information sharing in the groupware context leads, for example, to unexplored problems in distributed systems and user interface designs that emphasize groupware interactions. A prototype X-based group collaborative editing syslem,

Figure 8. The multiway talk of MGEAT Vol 35 No 11/12 November/December 1993


X Window based group collaborative editing system MGEAT, is presented. It is a real-time groupware. It allows group members simultaneously to edit in text, graphics, and hand-drawing documents. It also provides multimedia file transfer, text-based message interchange, on-line multiway talk and the verbal spoken subsystem to make the whole group work running smoothly. There are still some problems in our system which need to be overcome. Firstly, the response time and notification time might not be good enough when group members are very dispersed, because the concurrency control of the system is centralized. We should find a better solution to improve this. Secondly, the fault-tolerance in the system is not added. If any machine crashes suddenly, it will affect the whole system. In addition to the problems mentioned above, the future works about our system include the group editing of image and voice, integrating multimedia documents into a single document and extending it to a group hypermedia system. Certainly, we also hope the progress in hardware (machine itself and communication link) could increase the speed and performance of our system.

ACKNOWLEDGEMENTS This research is partially supported by the Telecommunication Research Lab. under the contract No. TL823201.


REFERENCES 1 Poggio, A, Garcia, J J et al. 'CSCW: a computer-based, multimedia information system', IEEE Computer (October 1985) pp 92-103 2 Rodden, Tom 'A survey of CSCW systems', Interacting with Computers Vol 3 No 3 (1991) 3 Vin, Herrick M et al. 'Multimedia conferencing in the Etherphone Environment' IEEE Computer Vol 24 No 10 (October 1991) 4 Sarin, S and Grief, I 'Computer-based real-time conferencing systems' Computer Vol 18 No 10 (October 1985) pp 33-45 50lunori, T et al. 'Distributed cooperative control for sharing applications, based on multiparty and multimedia desktop conferencing system: MERMAID' IEEE (1992) pp 538-546 6 Ellis, C A, and Gribbs, S J 'Concurrency control in groupware systems ACM Sigmod (1989) pp 399-407 7 Stefik, M e t al. 'WYSIWIS revised: early experiences with multiuser interfaces' ACM Trans. Off:. Inf. Syst. Vol 5, No 2 (April 1987)pp 147-186 8 Shen, Honghai and Dewan, Prasun 'Access control for collaborative environments' ACM CSCW Proc. (November 1992) pp 1-16 9 Greif, Irene and Sarin, Sunii 'Data sharing in group work' ACM Trans. Office Inf. Syst. Vol 5 No 2 (April 1987) pp 187-211 10 Newman-Wolfe, R E and Pelimuhandiram, Harsha K 'MACE: a fine grained concurrent editor' Proc. ACM/IEEE Conf. Organizational Comp. Syst. (COCS 91) (November 1991) pp 240-254 11 Ellis, C A, Gribbs, S J and Rein, G L 'Groupware--some issues and experiences' Comm. ACM, Vol 34, No 1 (January 1991) pp 38-58

Information and Software Technology