Cooperative hypermedia editing with CoMEdiA

Vol. 8 No.3 J. of Comput . Sci. & Technol. 1993

Cooperative Hypermedia Editing with CoMEdiA Adelino Santos

Fraunhofer-Arbeitsgruppe fiir Graphische Datenverarbeitung Wilhefr~nenstr, 7- 6100 Darmstadt, Germany

Received December 18, 1991; revised July 28, 1992.

Abstract

CoMEdiA is a groupware tool which enables co-authors to cooperatively produce hypermedia docu-

ments. CoMEdiA allows co-authors to communicate their ideas, drafts, guidelines, constraints and annotations to other co-authors. It uses a mix of communication patterns, media and document organization to enable co-authors to keep on exchanging information (remotely or face-to-face), improving passages and modifying notes until a final document is achieved. We did not concentrate on the depth but on the breath of the features. Our efforts were on integrating and coordinating concepts from collaboration, multimedia and hyper organization rather than on making a specialized system in any of them. We be- gan with the text medium and are now including bitmaps and raster images. Later sound and video will also be integrated. In this paper we describe and sustain the available capacities.

Keywords: Cooperative editing, groupware, hypermedia, multi-user interfaces, multimedia.

1. Introduction

In this paper we intend to describe a prototype of a cooperative editor called CoMEdiA- Cooperative hyperMedia Editing Architecture. This editor is intended to support cooperation among several authors, multimedia editing and functionalities for the non-sequential organization of files. CoMEdiA is based on the ideas of collaboration support, multimedia features and hyper organization. The most important concepts are the communication styles (Synchronous, Asynchronous and Off-document), hyper organization, multimedia integration, public comments, private annotations, selective telepointing, multi-user interface, social roles (Chairperson, Author, Secretary, Commenter and Reader), cooperation types (Brainstorm, Shared and Editor), access techniques (Chunk and Position), users' identification and WYSIWIS (What You See Is What I See).

CoMEdiA is to be used by groups of authors working in possibly different locations that want to collaborate (not compete) in order to produce a final document. We assume that every co-author works towards a goal of common interest, supports the other co-authors and promotes the progress of the group [351. Examples are the production of scientific reports, multimedia document editing demanding people with different backgrounds and views (newspaper articles, project proposals), source code production, design of rendering scenes for publicity (computer scientists working together with graphic designers and company managers), animation scripts or any kind of object modeling.

1.1. Rationale

Nowadays hypermedia editing is a topic touched by numerous researchers. The same happens with computersupported cooperative work (CSCW) which brings new potentialities to computer science in general. In this work we explore the promising advantages of merging these fields.

There is a number of different approaches to the development of cooperative multimedia editing systems. One way is to modify existing single-user, single-medium systems. This has the advantage of producing quick results and the users may already be familiar with the systems

258 J. of Comput. Sci. & Technol. Vol. 8

facilitating their adaptation to the new system. However, it is difficult to find a set of single-user tools that is broadly accepted. Usually, appropriate cooperation and communication are not supported. The multi-user interface and media integration would generate another bundle of problems.

We adopted another approach. Namely we have been studying and combining state-of-the-art research on social aspects of cooperative editing ([14, 16, 22, 30, 29, 17, 40, 28, 37, 5, 6, 35, 1] ), hypertext and hypermedia concepts ([11, 2, 20, 9, 39, 10, 15, 27] ), field studies on cooperation ([14, 1, 38, 40, 7] ), notions of multi-user interfaces ([41, 40, 29, 30, 4] ) and existing prototypes ([8, 20, 4, 23, 12, 36] ). The result is the research, presented here, made beyond some open points, the know-how acquired and the present implementation of the prototype CoMEdiA.

1.2. Theoretical Framework of CoMEdiA

In [19] a Cooperative HyperMedia (CHM) model is introduced. The model defines the notions of multimedia, cooperation and organization as the main components of documents.

It defines a CHM cube to relate these 3 orthogonal components (Fig. 1). The cube is used to classit~ documents and existing systems. It forms a 3D-subspace having in the origin systems that are single-user, single-medium and flat organized. We divide the CHM in little unit cubes (Fig.1 shows 5 x 4 x 4 =80 unit cubes). Each application fills up a number of unit cubes and the best cooperative hypermedia application would fill up the 80 little cubes (see Fig. 1).

Ascooperative editing refers to the way co-authors use an application (less to what is produced by the cooperation) and multimedia refers to what is produced by the integration of media, we had difficulties in conceptually integrating them. We devised a new definition for multimedia. The focus is not on the media, but on the systems that process these. To reflect this indirect handling we called it Indirect MultiMedia (IMM)i331. A traditional multimedia system processes the media directly and the single medium concepts loose importance. In an IMM system the functionalities are not delivered to the user but to the IMM system. The later gets unrelated functionalities from the single-medium systems and delivers them integrated.

Let's look at typical computer graphics systems (animation, radiosity, modeling, information editing) not as systems that deliver functionalities to the user but as libraries that make them available to a IMM system (see Fig. 2). The existence of a Functionality Interface between the libraries and the IMM system has some advantages. This avoids the usual disadvantages of any

M

/v=. / ,-" ="= A== I Graphic= I o "~

Non-Interactive ! B a s ~ ~ ~

Com, / I

Hierarch~cz~

Fig. 1. The classification of CoMEdiA in the CHM cube.

No.3 Cooperative Hypermedia Editing with CoMEdiA 259

generaI-purpose system, which are the complexity of conceptualization and the weight of implementation. The libraries can be accessed in a certain cooperative mode, with a certain media content and using a de~nite organization type I33' 191 Following Fig. 1 , the cooperative mode can be defined as Non-Interactive, Basic, Complex or Hierarchic, the media can be Text, Graphics, Sound, Video and Animations, and the organization type can be Flat, Simple, Back or Semantic1331~ There is a function to initialize an editing session: IMM_Use (CooperativeMode, ContentType, Organizat ionType).

IMM1

IMM-Use (C, Lib-Text, S) IMM-Use (H, Lib-Raster, B)

IMM-Use(C. Lib-Text, S) IMM-Use(H, Lib-Raster. B) IMIVI-Use(N. Lib~qound. B)

tLib oxtl

Funcli()nah'ty Interface

Fig. 2. indirect multimedia and the functionality interface.

2. Results Achieved

One of the difficulties in building cooperative multimedia editing tools is that it touches diverse problems on distributed systems, multi-user intert~aces, media integration, hyper organization, communications, version management, psychology and human factors.

First we have carried out research on communication mechanisms, cooperation control and user interfaces in order to have a prototype rapidly available. CoMEdiA is a tool that hits back the costs and restrictions associated with face-to-face communication and the demand for synchronous availability associated with telephones [141. Due to the 3 communication schemes supported it enables the interactive communication that other cooperative editors (DistEdit , Quilt, see 3 . 1 ) and computer mediated communication schemes (e-mail or tele-conferencing) lack. CoMEdiA enables co-authors to work in the same room (face-to-face) or in remote locations within a LAN (it has been used across two different buildings of our institute to edit its own source code) . In Fig. 3 the main window of CoMEdiA is shown.

The algorithm used to support cooperation in CoMEdiA has its origin in distributed systems f24. 32. 3I The Ordering Algorithm ~t~I implements Iogicat time stamps and a total order. It enforces a negotiation between the processes of each co-author to solve conflicts in the accesses to the document. It guarantees mutual exclusion and serialization in the access. It prevents deadlocks and starvation of any of the co-author processes, the fairness property is respected and the global consistency of the document is maintained.

2.1. Cooperation and Communication Features

Here we describe the features that best support co-author cooperation, e. g. private annotations, public comments, tele-pointing, multi-cursors, communications, social roles and cooperation types.

2.1.1. Private Annotations

A private annotation is an information fragment that refers to a certain point of the docu-


ment and expresses an idea about this point. In the current version, it is a piece of text to be displayed in a separate window. The annotations are recursive, so to say, there can be annotations on annotations. Their functioning is' based on a hypermedia model - - - - t h e y can be accessed following a link and there is an icon in the margin of the document to mark their presence. They are private in the sense that each co-author maintain his/her own pieces of information that refer to a certain part of the document. An annotation has a key (given in the crea- t ion) that is displayed together with the annotation and can be used for searching. A private annotation can be turned in a public comment. There are the NEW, OPEN, KILL, PRINT, SEARCH and MAKE PUBLIC options (sse Fig. 3).

2.1.2. Public Comments

A public comment is like a private annotation except that it is public.. It is used to explicit- ly transmit information to the group. In the current version, it is a piece of text to be displayed in a separate window. Like the annotations they are recursive and their functioning is based on a hypermedia model. A comment has a key that is displayed together with the comment and can be used for searching. There are the NEW, OPEN, KILL, PRINT and SEARCH options

(sse Fig. 3).

Fig. 3 �9 Main window of CoMEdiA �9

2.1.3. TelePointing, Multi-cursors and Follow Coauthor

A tele-pointer is a mean of directing the attention of the group to a particular document location. The tele-pointer in CoMEdiA is its logo (F ig . 3 top left corner) and it must be "picked" and "released". When a co-author is pointing something, the others are forced to stop what they are doing and passively follow. We can say that during the pointing the co-authors that do not point are "frozen" and just watch. This is a quite restrictive tele-pointing politic that can bring problems as we will see in 3.2.1. If a co-author wants the pointer but this

No. 3 Cooperative Hypermedia Editing with CoMEdiA 26l

is being used by another, then the first waits and the second gets a message saying " Hurry up. Co-author X is waiting tbr the tele-pointer",leaving the control on the politeness of the second co-author. There is a selection mechanism to specify from whom can a co author receive tele-pointing (selective tele-pointing). There are the PICK, RELEASE, To ME (putldown menu with the group members. The pointing actions of the marked ones cannot be seen. In the beginning there is no marked ones) and FROM ME options.

In the login of a session each co-author chooses a cursor (Fig. 4). The selected cursor is continuously shown to the other co-authors so that co-authors are aware of what is being done by all the members of the group. As this can lead to over-information (e.g, several co-authors editing in the same area), there is a mechanism to express which co-authors' cursors one wishes to see. The drawing of the cursors is made just if this authorization had been given and the two co-authors are in the same screen of the document. There is one option: CURSORS (pul!down menu with the group members. Just the cursors of the marked ones are visible. In the beginning there is no marked co-authors).

A co-author can follow another co-author's editing. The screens, become exactly the same with one of the co-authors being completely passive. The social roles define who can follow who. There are the BEGIN FOLLOW, END FOLLOW and PREVENT FOLLOW options.

2.1.4. Access' Techniques

We define two different kinds of access techniques (lock mechanisms): " chunk lock" and

Fig. 4. Login window.


" position lock". In the login window (see Fig. 4) the co-author chooses one and if it is not the one being used by the rest of the group then an unanimity must be reached. Using the chunk lock, the co-author requests chunks of the document for own use. This way, during the editing there are operation cycles over chunks-Select-Ask-Edit-Free. This is cumbersome because it requires too many actions. Using the position lock, the co-author has just lock of the position where (s)he is editing. There are the C H U N K EDIT and C H U N K FREE options.

2, 1.5. Synchronous, Asynchronous and Offdocument Communication

There are many definitions for (a ) synchronous communication. We adopt the following: synchronous communication implies communication of all group members at the same time and asynchronous communication enables participants to communicate without implying communication of all group members at the same time I261. In CoMEdiA co-authors can manipulate ob jects and see in real time the manipulations of the other co-authors ( W Y S I W I S ) . Thus, synchronous communication is provided by the editing per se. Asynchronous editing is supported because co-authors can work independently of each other's presence in the same work session.

Off-document communication enables the communication about the writing task (discussing about plans or concepts of the document, ways of writing a sentence) or about the document (discussing ideas or formats), as well as , about matters outside of the editing context (shall we play squash this evening ?). This is implemented using a window with an area to read, another to write and some buttons (see Fig. 6) .

When a co-author wants to talk to another that is not using CoMEdiA at that moment, he can still let messages in the offdocument window as if the other would be there. When the second one arrives he can read the message that has been left.

CoMEdiA can show diverse information about the co-authors, namely name, personal data, cursor used, login time, actual editing position and social role (see Fig. 4) . This information is displayed in a special window whenever the co-author selects the option "users' information " in the ~Cooperate" menu or in the login window (see Fig. 3).

2. 1.6. Social Roles

One response to the cooperation problem is the definition of social roles. This reduces the coordination problems by specifying ~ proper behaviours " (responsabilities, permissible actions, restrictions, patterns of interaction) of the group members. The social roles implemented in CoMEdiA (see Fig. 4) are chairperson (chairs an editing session), author (one of the participants in the meeting that actively contributes to the production of the document ),secretary (takes care of the management and general support activities), commentator (just has rights to comment on the authors writings) and reader (just has rights to read the authors writings). For several purposes we define that the social roles are ordered. The social role of each of the participants in a meeting is defined in the login and not all the roles available have to be used.

2. 1.7. Cooperation Types

Cooperation types exist to define the way co-authors can modify documents. They just apply to the roles "chairperson" or ~ author" (these are the only ones that can modify a document) . CoMEdiA is prepared to support the cooperation types (see Fig. 4), brainstorm all the co-authors can freely modify the document and there is no conflicting access control, share the co-authors modify the document in an F IFO manner (in case of conflicts) and editor just one the co-author ( the chairperson) can modify the document. In the current version just the shared type is implemented~

2.2. Multimedia Features"

In the present version there is just the text medium available. The usual text editing

No.3 Cooperative Hypermedia Editing with CoMEdiA 263

functionalities are implemented. There are commands to process documents as a whole New , Open, Close, Save, Save as and Print, commands that implement customary edit f u n c t i o n a l i t i e s - UNDO, COPY, PASTE, CUT, CLEAR, SHOW CLIPBOARD, SEARCH and SUBSTITUTE, and general purpose c o m m a n d s - - ABOUT and QUIT options.

2.3. Hyper Organization Features

The central notion of any non-flat organization, hyper-link , is supported by CoMEdiA. Each hyper-link has an arbitrary zone (sensitive zone) as

origin, an arbitrary location in the document as target, a key and a label. The key represents a layer to which the link be- longs~ The only semantic function of these layers is that a net of nodes connected by links with the same key can be formed and manipulated. This way there is the overall net of links and nodes and, also, all the sub-nets that the co-author forms using the keys. This enables not only the non-sequential organization of a document but also the simultaneous presence of diverse organizations. The label is just a comment to the link. This label is to be displayed when the link is navigated or back-navigated. CoMEdiA incorporates a hyper-link editor with the following options: Create, Delete, Navigate, Back Navi- gate, End Navigate, Change Label, Key (pulldown menu with Change, Search, Browse) and Browse (see Fig. 5). Fig. 5. Hyper organization menu.

3. D i scuss ion o f the Resu l t s

First we present some related work and then we compare it with CoMEdiA. A. Here, we aim at showing the wise of our work and sustaining the conceptualization options.

3.1. Related Work

Different approaches to the problems of cooperative multimedia editing have been taken and several prototypes have been built. Some examples (much more exist) follow.

ShrEdit [361 is a multi-user text editor that allows a group of users to edit simultaneously a text file having true concurrent access to it. The changes are reflected for all the users and a position lock mechanism. It minimizes unnecessary lock conflicts by minimizing the access units (text insertion position instead of a text chunk). It provides neither private annotations nor multimedia capacities and there is no users' identification (e. g. the position of the editing operations of the co-authors is not shown). The user can "park" him/herself, being then just a watcher.

Quilt[Zs. 121 is a collaborative document production system that is based on observational studies of writers. It concentrates on user communication and annotation but also provides revision suggestion, messaging and notification facilities. It combines concepts of social aspects of the writing task, hypertext and direct-manipulation interfaces. It provides social roles (co-author, commenter and reader) and cooperation types (shared, exclusive and edi tor) . The user can customize the difinitions of document, annotatons, social role and access permissions.

PREP [291 focuses on enhancing the effectiveness of loosely-coupled collaboration. It uses organizational techniques other than the usual text editors with great emphasis on hypermedia techniques as in Neptune fill, HyperPicture I2~ KMS I2l, InterNote I91, gIBIS [1~ or HyperBase [39]

It allows users to create chunks, which correspond to ideas (containing text, grids, trees and images) and links connecting the chunks so that the user can build networks of ideas. To support collaboration the system allows the creation 9f related columns of chunks. One column can form the contents of a paper and another the paper plan. Comments can be added in another column as well as annotations and notes. It supports social roles (co-author, commenter and reader),


comments and communication about plans. DistEdit [211 is a toolkit that can be used to build cooperative deitors out of traditional

single-user editors.The sense of the word ' )ooperative" is here limited but still DistEdit presents some good features. Almost any single-user editor can be easily transformed in order to support collaboration. It supports the use of different editors within the same editing group and so the users do not need to get used to a new application in order to collaborate because all the functionalities and interface mechanisms are maintained. It provides two social roles (master and observer) although just the master role has editing capacities and there can be just one master at a time. There are no multi-user interface, asynchronous communication or cooperation types.

ICICLE TM stands for "Intelligent Code Inspection Environment in a C Language Environ- ment". It is intended to augment the efficiency of formal code inspection~ It supports knowledge-based analysis of the source code, margin annotations, cooperative discussion and comments during inspection meetings. It implements social roles (moderator, reader, scribe, author and inspector) and tele-pointing and it supports a form of relaxed WYSIWIS. It is not to be used remotely.

Aspects [41 combines text, graphics and pixel images in a joint editor. Like in DistEdit a scheme for combining and augmenting single-user, single-medium applications was used. The user can create the documents or use the ones that have already been created by other single:medium, single-user applications. It has the advantage that the users do not need to get used to a new applicatio n in order to collaborate, it supports WYSIWIS and there is one cursor for each user (but no other forms of user's identification). It provides roles (master and participant) and cooperation types (free-for-all, medium and full mediations).

3.2. Justification and Comparison of Features

People that participate in group editing have a cognitive architecture that has well known characteristics. Perception is excellent, short-term memory is flexible and rich but slow and inaccu- rate and learning is powerful but similarly slow E3~ We also know that user-system and user-user communications have a key importance in cooperation. The user interface of CoMEdiA has several aspects bent on by the multi-user nature. It gives a good general perception of the cooperative editing process and of the document state, enhancing the commumcation and interaction. For example, it tries to constantIy deliver information that would require extra effort for the users' short-term memory (e.g. identification of the co-authors that are in an editing session or what are they doing) . Also it makes extensive use of permanent visual signs to show the state of the cooperative editing. For example CoMEdiA shows a " hand-up " bitmap to show that someone is asking access to a chunk; it has one cursor for each co-author and one extra for tele-pointing; there are different bitmaps to express which window have public and private information.

3.2.1. Cooperation and Communication Features

Private annotations Annotations are, like in traditional e&ting, a practical mean tocatch ideas and facts. On the other hand, although the addition of a message could result helpfully (capturing an idea before it is forgotten), making it public immediately can bring unnecessary reactions and critics. Consequently to express an idea in private is a necessary feature as well as to make it public. Although some systems support private annotations (Quilt , . PREP, ICICLE) , none has the " make public" feature.

Public c o m m e n t s - - Comments are a mean to support one of the most common events in a co-authoring relationship, i.e. the " edit-review-incorporate" cycle (one author gives the draft to another and the second revises it , leaving the first author to incorporate the new material) . PREP includes rather complex comment features whereas Quilt (revision suggestion) and ICI- CLE present simple comment features.

T e l e - p o i n t i n g - - It is useful to be able to direct the attention of the co-authors to a particular location within the display (as happens in any Pace-to-face meeting)An CoMEdiA, as there

No. 3 Cooperative Hypermedia Editing with CoMEdiA 265

is no mechanism to impose behavior rules on the use of the tele-pointer, nothing can prevent a co-author from using it too much and becoming annoying to the others. In this case the only thing that could be done is to disable the tele-pointer. But this would prevent a co-author from receiving any tele-pointing f romany other co-authors. In CoMEdiA each co-author can express to whom and from whom does the tele-pointer work. Nevertheless, we relay on a certain " sensible" behavior of each co-author. In the future when we include audio and video we will include them in the off-document communication that will overcome some of these problems. Just ICICLE includes a tele-pointing mechanism. Just Aspects has multi-cursors and no system has the "follow co-author" feature.

Fig. 6. The oil:document communication window.

Access t e c h n i q u e s - - The advantage of working with chunk lock is that the co-author has the guarantee that no one will disturb his/her work during the editing. It can be made more co-author friendly if the Select.Chunk and Ask.Chunk operations (see 2 . l .4 ) are put together in the same action. It is much more prone to access conflicts and has common disadvantages with the distributed file systems that make file locking. Using position locking the co-authors have more editing freedom but overload more the system. The latter is much more user friendly and, as long as the co-authors can see where the others are located in the document it is easy to use (a co-author can always see the cursors of the others, if (s)he wants). On the other hand it can be difficult for two co-authors to edit the same paragraph (e.g. seeing lines moving at the speed of double insertion). ShrEdit implements position lock but no system supports both mechanisms.

Communications It is very important to have a WYSIWIS politic, otherwise problems can appear-members' interest for the group task or group cohesion can diminish. But , the most serious problem of a non-WYSIWIS politic would be the lost of synchronous communication's advantages. Nevertheless, the WYSIWIS style of CoMEdiA contrasts with the systems consisting of one machine whose display is projected onto others via a facilitator (Dist Edit, Aspects or Shared windows applications). ShrEdit, DistEdit, ICICLE and Aspects have WYSIWIS.


One of the arguments against plain synchronous communications philosophy adopted is shown by the following example. A co-author writes a paragraph or makes a public comment, points it to the others and asks for a reply comment. If the responses are made using the same mechanisms (ordinary paragraph or public comment writing), they will be seen by all group members when the co-author that wrote the first comment should receive them. To avoid this su- perfluous communication the offdocument communication is very adequate. It enables a private dialogue between just two of the co-authors (there is a window for each pair of co-authors communicating this way). As a result groupwise information exchange can be made using the public comment mechanism, while pairwise information exchange can be made through the off-document communication mechanism.

Asynchronous communication is useful enabling co-authors to work alone or in sub-groups. Co-authors can communicate with others (that are not in the session), by leaving messages in public comments or using the off-document facility. The fact that a co-author can let a message in the offdocument window is a mixed form of off-document with asynchronous communication which is not present in any other system mentioned above. The combination of these communication features makes CoMEdiA contrast with other systems that just provide one of these types (Quilt, ICICLE or Aspects) or with document authoring and tele-conferencing tools. " Users' information" and "follow co-author" are features that are not present in any system mentioned in 3.1.

Social roles- We adopted the social roles that we consider necessary and sufficient for most of the cooperative editing meetings (Chairperson, Author, Secretary, Commenter and Reader). Inspite of the advantages of social roles we are aware of the restrictiveness introduced by them. We refer to some problems in Section 4 and because of them we have planned some extensions of the concept. Quilt, PREP, DistEdit, ICICLE and Aspects provide various forms of social roles. We think that the ones supported by CoMEdiA cover all these.

Cooperation types We adopted the cooperation types that we consider necessary and sufficient for most of the cooperative editing meetings (Brainstorm, Shared and Editor). Just Quilt and Aspects support cooperation types.

3.2.2. Multimedia Features Multimedia data are needed to enhance editing productivity. Experienced writers produce in-

termediate external representations that have no direct relation to the document. When working under environments that do not support any graphical primitives (arrows, boxes, grids, pies, etco )to show conceptual relationships between ideas, co-authors report frustration and important planning activity and brainstorming is reduced I~3' 71. More than just graphics, other media

(bitmaps, raster images, sound and video) enrich the documents' contents as well as documents' production process. These are planned for CoMEdiA and are the step that is being now taken. Just Aspects and PREP include multimedia features. DistEdit may eventually include depending on the application that is groupified.

3.2.3. Hyper Organization Features To many people, professionals as well as vendors, hyper structures have become " the way"

to organize documents [39] To a high degree, due to this it has been possible to develop rather advanced co-author interfaces and browsing mechanisms. In CoMEdiA the hyperstruc- tures are rather simple (see Fig. 5), compared with other systems that concentrate on them. Once more we say that we did not concentrate on the depth but on breath of the features. PREP has sophisticated hyper features, ICICLE and Quilt refer to them and ShrEdit, DistEdit and Aspects d o not have.

3.2.4. Summing Up We have been comparing the editing supported by CoMEdiA with both the traditional

group writing and single-user computer writing. CoMEdiA multimedia features will substitute and integrate the use of different single-media applications. Annotations and comments substitute mar-

No. 3 Cooperative Hypermedia Editing with CoMEdiA 267

gin jottings. Synchronous communication and WYSIWtS intend to replace face-to-face communication and version merging. Asynchronous communication handles the case that a co-author misses a meeting or has to leave for a couple of minutes. The other co-authors ' communicating intentions are not frustrated and information is not lost. The oil:document communication feature is designed to assist the co-author with the quick exchange of ideas, planning, conceptualization, coordination and informal side talks I351. CoMEdiA's (selective) tele-pointing substitutes the frequent action, in a traditional meeting, of calling the attention of all the group. Co-authors ' identification and login features provide protection and authorization features ~181 as well as substitute the 'self introduction in the beginning of the meetings. Finally, the hyper structures enable all the known advantages of non-sequential organization.

4. Future Work

The only usability study that has been made is that CoMEdiA has been used to edit its own source code. This is not a correct study either because of the people that are undertaking the experiences or because there is no appropriate control. A usability study is being elaborated and statistic results can, probably, be included in the final version of this paper. The study is composed by a group doing " source code inspection" and another " technical report writing" . A group will work in 4 sessions of 1 hour of code understanding, commenting and correcting. The people can communicate outside CoMEdiA about the task and they can use paper listings. The sessions will be video taped for analysis and a questionnaire is being planned. These and " on-line" critics will be used to produce the statistics and new requirements (ranging from window size to suggestions of new features). The second group will elaborate a scientific report. The co-authors just meet during the cooperative writing sessions (or else they do not talk about them), i . e . the group communication is all made through CoMEdiA. A similar evaluation mechanism will be used. The aspects in study are: editing capacities; cooperation support adequa- cy;partial ly v.s. exclusively supported cooperation; idea and plan communication; usefulness of the hyperfeatures supported.

One of the directions that we want to pursue is the so-called version management. The problem is emphasized by the cooperative nature of the editing. Some systems have rudimentary history mechanisms for attributes of changings. We want to support simultaneous editing of different versions .

Face-to-face contacts among co-authors, in which each individual's behavior is affected by the behavior of the others, are necessary.The inclusion of a video and sound channel using an

ISDN connection is being studied. This will help the development of affective ties [351 and en- force the synchronous communication capacities. To enhance the multimedia range of the documents ' contents is a priority.

Brainstorming, where a group of people generate ideas in a quick succession, is the classic technique for improving creativity through simultaneous work [35] For this reason we intend to provide a brainstorming zone (with pixel graphics).

It is easy to devise situations in which the social roles defined do not suffice. Moreover, we do not think that the predefined combination of social roles and cooperation types can be adequate to all cooperation situations. We want to include dynamic changing and temporary social roles. These are two notions that we are working on and that will be available in next version.

CoMEdiA is thought to be an IMM system. We have planned that in the login the co-author specifies the parameters of the IMM_Use and just the specified part is started. If a document is created with a certain " amount" of one of the 3 components it cannot be accessed using more than this " amount". If a document containing 3 media is used just with 2, then the locations that contain the third media appear black, with the editor having no functionalities available. This happens when 2 co-authors meet to change drawings but not the text or the animations o f a document. They do not need to be overloaded with the functionalities of the text and animation media. This means that the set of unit cubes in the CHM model used to create

268 J. of Comput, Sci. & Technol. Vol. 8

a document must contain the set used in any editing session. The CHM model is being ex- tended to include the notions of group , group member, editing session, time and IMM.

5. Conclusions

We have given the reasons why we find necessary to develop a cooperative multimedia tool. We have also substantiated the conceptualization. Following we describe the system achieved, jus- tify the options and compare it with other state-of-the-art approaches.

Although we are in the beginning and a considerable amount of work needs to be done towards the multimedia aspects of the system, we have already had a prototype and the know-how necessary to treat the problems of cooperation in multimedia.

Acknowledgem ents

Many thanks to Prof. J. Encarnac~o for the opportunities and suggestions given, to Kaisa Vgffngnen for the useful suggestions and discussions, and to Dr. Christoph Hornung for the support given.

References

[ 1] Aceves, J., Craighill, E. and Lang R., An Open-Systems Model for Computer-Supported Collaboration. IEEE Corrg)uter, 1988, 3 (2).

[ 2] Akscyn, R., McCracken, D. and Yoder E., KMS: A distributed hypermedia system for managing knowledge in organizations. Communications of the ACM, 1988, 31(7), 820-835.

[ 3 ] Ben-aft, M., Principles of Concurrent Programming. Prentice Hall, Englewood Cliffs, N. J., 1982. [4] Biel, V., Groupware Groups Up. MacUser, June, 1991. [ 5] Bly, S., A Use of Drawing Surfaces in Different Collaborative Settings . Proc. CSCW'88, 1988. [ 6] Bodker, S., Knudsen, J., Kyng, M., Ehn, P. and Madsen, K-, Computer Support for Cooperative De-

sign. Conrr~mications of the ACM, Sept., 1988. [7] Bftdwell-Bowles, L., Johnson, P. and Brehe, S., Computers and Composing: Case Studies of Experi-

enced Writers. Writing in Real Time: Modeling Production Processes, Norwood, 1987. [ 8] Brothers, L. and Sembugamoorthy, M., ICICLE: Groupware for Code Inspection. Proc. CSCW'90. [ 9] Catlin, T., Bush, P. and Yankelovich, N., InterNote: Extending a Hypermedia Framework to Support

Annotative Collaboration. Proc. Hypertext ' 89, Nov. [10] Conklin, J. and Begeman, M, gIBIS: A hypertext tool for explaratory policy discussion. ACM ToOIS,

1988, 6 (4).

[ 11] Delisle, N. and Schwartz, M., Neptune: a Hypertext System forCAD Applications. Tektronix Labs., 1986. [12] Fish, R., Kraut, R., Leland, M. and Cohen, M., Quilt:a Collaborative Tool for Cooperative Writing.

Proc. COIS'88, Conference on Office Information Systems, 1988. [13] Flower, L., Schriver, K., Carey, L., Haas, C. and Hayes, J., Planning in Writing: the Cognition of a

Constructive Process. TR 34, Center for the study of writing, Carnegie Mellon University, July, 1989. [ t4] Galegher, J. and Kraut, R., Computer-Mediated Communication for Intellectual Teamwork: A Field Ex-

periment in Group Writing. Proc. CSCW' 90. [15] Goodlet, J. and Pemberton, L., Designing the Writer's Assistant: Pratical Experiences of Using a

Hypertext Design Tool. Proc. AI in Design' 91. [16] Greenberg, S. Sharing Views and Interactions with Single-User Applications. Proc. Conference on Office

Information Systems, Cambridge MA, 1990. [17] Greenberg, S., Computer-Supported Cooperative Work and Groupware. Academic Press, ISDN

0 - 12-299220-2, 1991. [18J Hornung, C. and Santos, A. (91a),CoMEdiA: A Cooperative Hypermedia Editing Architecture: the

Problem of the Cooperative Access. Ist Eurographics Multimedia Workshop, Stokholm. [19] Homung, C. and Santos, A. (91b),Proposat for a Reference Model for Cooperative Hypermedia Sys-

tems. 1st Eurographics Multimedia Workshop, Stokholm. [20] Kirste, T., and Hbner, W., An Open Hypermedia System lbr Multimedia Applications. Eurographics

Multimedia Workshop, 1991.

No.3 Cooperat ive Hypermedia Editing with C o M E d i A 269

[21] Knister, M. and Prakash, A., DistEdit: A Distributed Toolkit for Supporting Multiple Group Editors. Proc. CSCW '90.

[22] Kraut, R., Galegher, J. and Egido, C., Relationships and tasks in scientific collaboration. Hu- ma~CorrgTuter Interaction, Vol. 3, 1988.

[23] Lai, K., and Malone, T., ObjectLens: A " Spreadsheet" for cooperative work. Communications o f the ACM, Sept., 1988.

[24] Lamport, L., Time, clocks, and the ordering of events in a distributed system. Comrr~nications of the ACM, 1988, 21(7), 558-564.

[25] Leland, M., Fish, R. and Kraut, R., Collaborative Document Production Using Quilt. C o g i t a t i o n s of the ACM, Sept., 1988.

[26] Lubich, H. and Plattner, B., A Proposed Model and Functionality Definition for a Collaborative Ed- iting and Conferencing System- Proc. IFIP '90.

[27] Lundeberg, A., Yamamoto, T. and Usuki, T., SAL : A Hypermedia Prototype System. Eurographics Multimedia Workshop, I991.

[28] McGrath, J., Time Matters in Groups. Intellectual Teamwork: the Social and Technological Founda- tions for Cooperative Work, Hillsdale, NJ: Lawrence Erlbaum Inc. 1990.

[29] Neuwirth, C., Kaufer, D., Chandhok, R. and Morris, J.,Issues in the Design of Computer Support for Co-authoring and Commenting. Proc. CSCW'90.

[30] Olson, J . , Olson, G . , Mack ,L. and Wellner ,P., Concurrent Editing :The Group's Interface.Proc. IFIP '90. [31] Rada, R. and Keith, B., Collaborative writing of text and hypertext. Hyperrnedia, 1989, 1(2). [32] Ricart, G. and Agrawala, A., An optimal algorithm for mutual exclusion in computer networks. Cornrr~

nications of the ACM, Jan., 1981, 24(1), 9 -17 . [33] Santos, A., Some Issues on Cooperative Multimedia Editing. 4th Portuguses Conference on Computer

Graphics, Lisbon, Nov., 1991- [34] Schendel, M., Noll, S . and Rix, J., Distributed SketchPadSystem. COMICS'91 Workshop. [35] Sharpies, M., Goodlet, J., Beck, E., Wood, C.,Easterbrook, S.,Plowrnan,L. and Evans, W. (n.d), A

Framework for the study on Computer Supported Collaborative Writing. n.p. (Draft), University of Sussex. [36] ShrEdit, ShrEdit 1.1: A Shared Editor for the Apple Macintosh. User's Guide and Technical Descrip-

tion. Cognitive Science and Machine Intelligence Laboratory, University of Michigan, Nov., 1990. [37] Stefik, M., Foster, G., Bobrow, D., Kahn, K., Lanning, S. and Suchman, L. Beyond the

Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings. Proc. CSCW' 88. [38] Whittaker, S., Brennan, S. and Clark, H. H., Co-ordinating Activity: an Analisys of Interaction in

Computer-Supported Co-operative Work. Comnemications of the ACM, March, 1991. [39] Will, U. and Osterbye, K., Experiences With HyperBase, A Multi-User Back-End for Hypertext Applica-

tions with Emphasis on Collaboration Support. Institute for Electronic Systems, Allborg, Denmark, 1990 o [40] Wulff, W., Designing collaborative user interfaces: lessons from writter/grapbic designer interaction.

SIGCHI Bulletin. 1990, 21(3). [41] Wulff, W., Evenson, S. and Rheinfrank, J., Animating Interfaces. Proc. CSCW'90.

Cooperative hypermedia editing with CoMEdiA

Documents

Transcript of Cooperative hypermedia editing with CoMEdiA