An Editing-Based Characterization of the Design Space of Collaborative Applications Prasun Dewan University of North Carolina Rajiv Choudhary Intel Corporation Honghai Shen IBM Corporation 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 The design space of collaborative applications is characterized using the notion of generalized multiuser editing. Generalized multiuser editing allows users to view interactive applications as editors of data structures. It offers several collaboration functions, which allow users to collaboratively edit application data structures. These functions include coupling, concurrency control, access control, and multiuser undo. Coupling allows the users to share editing changes, access control and concurrency control prevent them from making unauthorized and inconsistent changes, respectively, and multiuser undo allows them to collaboratively undo/redo changes. These functions must be performed flexibly to accommodate different applications, users, phases of collaboration, and bandwidths of the communication links. In this paper, we define and motivate the notion of generalized multiuser editing and describe some of the issues, approaches, tradeoffs, principles, and requirements related to the design of the functions offered by it.
3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
1. Introduction A large number of applications have recently been developed that allow users, interacting possibly from geographically dispersed sites, to collaborate with each other1-3. These applications, called collaborative, multiuser, or groupware applications, have the potential for automating the large amount of group work carried out in current organizations4. In particular, they have the potential for supporting group decision making 5, team software development6, a national ‘‘collaboratory’’7, distributed concurrent engineering8, and distributed classrooms3. 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 First author’s address: Department of Computer Science, University of North Carolina, Chapel Hill, N.C. 27599;
[email protected]. Second author’s address: Mail Stop HF3-02 Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, Oregon 97124;
[email protected]. Third Author’s address: IBM/Advantis, HCP 3C130, 1311 Mamaroneck Ave., White Plains, NY 10605;
[email protected]. This research was supported in part by National Science Foundation grants IRI-9015442 and IRI-9208319 and in part by a grant from the Software Engineering Research Center at Purdue University, a National Science Foundation Industry/University Cooperative Research Center (NSF Grant No. ECD-8913133).
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 2
Some important questions raised by the design of these applications are:
d
What are the dimensions of the design space of collaborative applications?
d
What are the design choices along each of these dimensions?
d
What are the advantages and disadvantages of making each of these choices?
d
What are the design principles and requirements of collaborative applications?
We refer to a set of answers to these questions as a ‘‘characterization of the design space of collaborative applications’’. Such a characterization would improve the understanding, design, and automation of collaborative applications:
d
Understanding: It would allow those studying this area to understand the nature and scope of collaborative applications and what distinguishes these applications from single-user applications.
d
Design: It would tell designers of these applications the design decisions they need to make, the tradeoffs in choosing among these decisions, and the design principles and requirements they must support.
d
Automation: Implementation of collaborative applications from scratch is difficult and typically takes several person years9. Therefore, system support for automating their implementation is an attractive idea. It is not possible to provide such support without knowing the design space of collaborative applications. In this paper, we do a preliminary, high-level characterization of the design space of collaborative applications
based on the notion of generalized multiuser editing. Generalized multiuser editing is an extension of generalized single-user editing10, which allows a user to view an interactive application as an editor of the data structures of the application. It offers several functions to allow users to collaboratively edit these data structures. These functions include coupling, concurrency control, access control, and multiuser undo. Coupling allows the users to share editing changes, access control and concurrency control prevent them from making unauthorized and inconsistent changes, respectively, and multiuser undo allows them to collaboratively undo/redo changes. We characterize the design space of collaborative applications by characterizing the design space of each of these functions. Our characterization is not complete, for two main reasons. First, not all issues, design choices, tradeoffs, principles and requirements are currently known for all functions. Our characterization reflects the state-of-the art in this area. Second, we focus mainly on high-level concepts in the characterization— lower-level, more specific, concepts required to support some these ideas are given elsewhere11-13. See2, 14-16 for alternative characterizations of collaborative applications, which are not based on the notion of generalized multiuser editing. Our approach represents a method for dimensionalizing the design space of collaborative applications that addresses collaboration at the ‘‘common object perception’’ level in Malone and Crowston’s collaboration hierarchy of coordination, group decision making, communication, and common object perception16. The particular technical dimensions we have chosen at this level are consistent with the ones identified by other researchers2, 14-16. The rest of the paper is organized as follows: Section 2 identifies and motivates two important properties of an effective design space characterization—generality and detail. Section 3 explains the ideas of single-user and multiuser generalized editing and introduces the collaboration functions. Section 4 characterizes the design space of each
Characterizing Collaborative Applications d 3
Dewan, Choudhary, and Shen
of the collaboration functions. Finally, Section 5 provides conclusions and directions for future work. 2. Defining a Collaborative Application In this section, we propose and evaluate two simple but extreme definitions of collaborative applications to motivate a more complex, editing-based definition of these applications. A general definition: A collaborative application is a software application that (a) interacts with multiple users, that is, receives input from multiple users and displays output to multiple users, and (b) couples these users, that is, allows one user’s input to influence the output displayed to another user (Figure 1). This definition covers all possible collaborative applications since it leaves the nature of coupling supported by a collaborative application undefined. It contributes somewhat to the understanding, design, and automation of collaborative applications. It tells those (a) understanding collaborative applications that multiuser interaction and coupling are the essential differences between collaborative and single-user applications, (b) designing these applications that, in addition to single-user issues, they must address issues in multi-user input/output and coupling, and (c) automating collaborative applications that they must provide facilities that allow an application to interact with multiple, possibly distributed, users. On the other hand, because it leaves the nature of coupling and associated functions unspecified, it does not convey any information about the issues, choices, tradeoffs, principles and requirements related to the design of collaborative applications. As a result, it is not possible to use this definition to gain a detailed understanding of the design space of collaborative applications or to provide high-level support for implementing these applications. The next definition meets these requirements. A detailed definition: A collaborative application is a software application that interacts with multiple users and creates one or more shared windows, which are replicated on the screens of all users of the application. Coupling between the users ensures WYSIWIS (What You See Is What I See)17 interaction, that is, keeps the contents of the windows identical (Figure 2).
Software Application
Coupling User 1
User 2
Figure 1: A General Definition of a Collaborative Application
Characterizing Collaborative Applications d 4
Dewan, Choudhary, and Shen
This definition allows collaborative applications to be understood in terms of the specific notion of WYSIWIS. It also precisely states how coupling between users should be designed. Finally, this definition can be used to build a system such as a shared window system18 that completely automates multiuser interaction and coupling without making the applications collaboration-aware. The second definition leads to these benefits because it qualifies the nature of collaboration in a collaborative application. However, a serious drawback is that it overqualifies the nature of collaboration since several applications such as traditional mail programs and recent collaborative applications such as the GROVE group editor 2 do not support WYSIWIS. Thus, while the definition is detailed, it is not general. In the rest of the paper, we develop a definition that is both general in that it does not preclude useful collaborative applications and detailed. Like the second definition above, our definition has a fixed part that defines the invariants of collaboration and like the first definition above, it has a set of variables which define the collaboration design space. 3. An Editing-based Definition Before we can model the interaction between multiple users and an interactive application, we should be able to model the interaction between a single user and an interactive application. Generalized single-user editing 10 (Figure 3) allows us to model the simpler case of single-user interaction. According to this model, an interactive application can be considered an editor of a display of the data structures of the application. A user interacts with the application by editing the display using text/graphics editing commands. Thus, interaction with an interactive application is similar to interaction with a text or graphics editor. The difference is that the display is ‘‘active’’, that is, changes to it can trigger computations in the application, which can update the display and send messages to other applications. Generalized single-user editing is a simple but general model of single-user interaction. It models a variety of popular contemporary interactive application: A text or graphics editor can be considered an editor of a text or
Software Application
WYSIWIS Window 1
Window 2
Window Commands
User 1
User 2
Figure 2: A Detailed Definition of a Collaborative Application
Characterizing Collaborative Applications d 5
Dewan, Choudhary, and Shen
graphics file; a language-oriented editor can be considered an editor of a program syntax tree; a spreadsheet can be considered an editor of a matrix that responds to an editing of an entry in the matrix by updating related entries; and a debugger can be considered an editor of a debugging history that responds to the insertion of a new command in the history by computing the command and appending the output to the history. At some level of abstraction, any single-user interactive application can be considered a single-user generalized editor. The challenge, then, is to introduce multiuser interaction into this model. Figure 4 shows how this can be done. As before, a user interacts with an application by editing an active display of the data structures of the application. Different users, however, edit different versions of the active display. Coupling between the displays allows them to share editing changes; multiuser undo allows them to collaboratively undo/redo changes; and access and concurrency control prevent unauthorized and inconsistent changes, respectively. Moreover, in the multiuser case, the application is persistent. In the single-user case, it is possible to tie a single-user session with an application so that when the user quits the session the application terminates. In the multiuser case, it is not possible to do so since a user may start and terminate a session at any time. Thus the application must persist beyond any particular user session to allow users to dynamically enter and leave collaborative sessions. Together, coupling, undo, concurrency control, and access control define a new multiuser transaction model designed for interactive multiuser applications. The model is an alternative to the query-based transaction model supported by traditional databases, which has been designed mainly for batch applications. The arrows withing the circles of Figure 4 represent user-/application- controlled dials and indicate that the collaboration functions must be performed flexibly. We characterize below the design space of each of these functions. 4. Collaboration Functions Some of the general principles for designing collaboration functions are independent of the function:
Application
Active Display Editing Cmds User
Figure 3: Generalized Single-User Editing
Characterizing Collaborative Applications d 6
Dewan, Choudhary, and Shen
Persistent
Application
Active Display Version 1
Cplng Undo
Concurrency
Editing Cmds
Access User 1
Redo
Active Display Version 2
Control
Editing Cmds
Control
User 2
Figure 4: Generalized Multiuser Editing
d
Specification: The model should make it easy for users to specify how a collaboration function should be performed.
d
Grouping: A corollary of the specification principle is that the model should allow users to specify a collaboration parameter once for a group of objects that share its definition instead of once for each member of the group.
d
Performance: The model must not make the response time of programs unacceptable.
d
Automation: The model should make it easy for programmers to implement a collaboration function. We shall see below (functions-specific) principles that require the collaboration functions to be performed
flexibly. The principles above require that flexibility not be introduced at the expense of easy specification, performance, and automation— otherwise, users and programmers would be unwilling to use the model. 4.1. Coupling Coupling determines how coupled interaction occurs among the users of a collaborative application. In particular, it determines which users share a change made by a user and when the change is communicated to them. Two main alternatives for coupling are WYSIWIS coupling, mentioned earlier, and WYSINWIS (What You See Is Not What I See) coupling. WYSIWIS ensures that any change made by a user is communicated immediately to all other users. In particular, it ensures all users share the same sizes, positions, cursors, and contents of their edit windows. There are several advantages of supporting WYSIWIS coupling: First, it is the ideal coupling in meetings that require very close collaboration. For instance, in a group demonstration of a program, the demonstrees might want WYSIWIS coupling so that they can see every action made by the demonstrator. Second, WYSIWIS is easy to understand in that each user knows what the other user is seeing. Finally, WYSIWIS can be defined in an application-independent fashion, and thus can be automatically supported by a general system such as a shared window system 18, which collects input from all users and broadcasts output to them. Clients of such a system do not have to be aware that they are interacting
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 7
with multiple coupled users. However, WYSIWIS coupling has two main disadvantages. Researchers have found that it can lead to ‘‘window wars’’ and ‘‘scroll wars’’ as users position windows and scrollbars at different positions 17. Similarly, it can lead to ‘‘view wars’’ and ‘‘format wars’’ as they try to create different views and formats for the editable data structures. In general, it can lead to wars whenever users are forced to share changes they do not want to share. Second, WYSIWIS requires the overhead of communicating all user changes to all of the other users, which is inefficient, specially when the users do not wish to share some of these changes. WYSINWIS does not have these disadvantages but does not have any of the advantages of WYSIWIS either. What is necessary, then, is a coupling model that allows the coupling between users to be tailored to the level of the collaboration among the users. Specifically, the design of a coupling model should be based on the following principles:
d
Need to tell: Local editing changes sent to remote users should contain no more than the information that the local users wants to tell the remote users. Otherwise, the coupling is not secure and remote users may take actions based on information that was not meant for them. This principle is in the spirit of the ‘‘need to know’’ or ‘‘least privilege’’ principle in access control mentioned later.
d
Need to learn: Local editing changes sent to remote users should contain no more than the information that the remote users want to learn about. Otherwise, they get information overload. Moreover, the information received sometimes destroys some of receiver’s information, and therefore getting unwanted information can cause undesired information destruction.
d
Need to collaborate: Local editing changes sent to remote users should contain no less than the intersection of the information the local and remote users want to tell and know, respectively. Otherwise, some collaboration that the participants are interested in may not be facilitated.
We can summarize these three principles by the following sharing principle: Sharing principle: Local editing changes sent to remote users should contain the intersection of the information the local and remote users want to tell and know, respectively. The principles above address which changes made by a user should be communicated to other users. The following analogous principles address when these changes should be communicated:
d
Time to tell: Local changes should not be seen by remote users sooner than the time the local users wants them seen. Otherwise, the coupling is not secure and the remote user may take actions earlier than wanted.
d
Time to learn: Local changes should not be seen by remote users sooner than the time the remote users wants to see them. Otherwise, they get information overload and premature destruction of local editing state.
d
Time to collaborate: Local changes should not be seen by remote users later than the later of the times when the remote and local users wants to tell/know about the contained information. Otherwise, some possible collaboration will be unnecessarily delayed.
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 8
These three principles are summarized by the following principle:
d
Timing principle: Local changes should be seen by remote users at the later of the times the remote and local users wants to tell/know about the contained information. As designers of coupling models, we do not know what particular users would like communicated and when
they would like the communication to occur. So one approach to meet these principles is to require them to manually define the desired coupling, but this approach violates the specification principle. Another extreme approach is to define a single rigid coupling, which is easy to specify but in several situations may be not be flexible enough. What we need is a set of concrete requirements that, based on collaboration scenarios, describe the kind of flexibility users would want. We give below an initial set of flexibility requirements:
d
Data independence: It should be possible for users to couple different data structures differently. Data independence allows users to collaborate differently on different data structures. In particular, it allows them to create both private and public data structures. For instance, it allows a group of users to create a shared list of procedures but private comments on these procedures.
d
Property independence: Users should be able to determine which properties of an editable data structure are shared among them. In particular, they should have the choice of determining if the viewing and formatting properties of the data structure are shared. For instance, users of a multiuser debugger may wish to display the same image of a single shared state on all workstations so that each of them can see the cause-effect relationships, while users of a multiuser program editor may wish to see different views of the program.
d
Asymmetric coupling: It should be possible for a user to share certain kinds of changes with another user without requiring the latter to share the same kinds of changes with the former. This requirement would allow for instance, managers to observe the work of employees but not vice versa.
d
Sender and receiver control: Both the local and remote user should be able to determine the content and timing of the information communicated from the former to the latter —a direct consequence of the need to tell and need to know principles.
d
User independence: It should be possible for a user to be coupled differently with different users since different users may wish to collaborate at different levels. For instance, a programming-language tutor interacting with a multiuser program editor may wish to see raw values input by beginning students; syntactically correct values input by intermediate students, who may not need help with the syntax of the programming language; and semantically correct values input by advanced students, who may not need help with the semantics of the language.
d
Dynamic coupling: It should be possible for the coupling among users to be changed dynamically. Dynamic coupling is useful since users may want to couple at different levels during different phases of the collaboration. For instance, during the ‘‘outline phase’’ of a requirements document, users interacting with a multiuser document editor may wish to see a change as soon as it is made since they would be collaborating closely on defining the outline of the document; during the ‘‘writing phase’’, they may wish to see a change only after it has been committed since they would be working on separate tasks; and finally, during the ‘‘integration
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 9
phase’’, they may wish to again see a change as soon as it is made. It also allows the coupling level to be adapted to support minimum performance levels. The response time of multiuser programs depends on the kind of coupling among its users— decreasing the level of coupling decreases the number of notification events generated and thus also decreases the response time of the program. This phenomenon can be used to dynamically ‘‘tune’’ the coupling of a multiuser program based on the maximum response time acceptable to its users. For instance, parts of the design of a software module created by a user of a multiuser program editor can be shared with other users as soon as they are created or after the design is completed, depending on the maximum response time acceptable to the users of the editor.
d
Recognizing dependencies: The requirements above indicate the kind of independences a generic coupling model should support. However, in specific situations, not all of these independences are relevant. For instance, in some situations, listeners may be willing to receive any information sent by senders of the information. When such dependencies exist, the coupling model should not force the users to enter, duplicate, redundant information— a direct consequence of the specification principle. For instance, in some situations, listeners may be willing to receive any information sent by senders of the information whenever the information is made available to them. In these situations, the model should not require the listeners to enumerate the the information they are willing to receive and when they are willing to receive it. This information should be automatically derived from the specifications made by the senders. Similarly, the model should allow specifications to be made for groups of data, properties, and users. Thus, a generic collaboration model must give users great flexibility in choosing the nature of the coupling
while also meeting the generic principles of easy specification, performance, and automation. 4.2. Concurrency Control Concurrency control prevents concurrent, possibly distributed, inconsistent changes to the editable data structures of a collaborative application. It is similar to access control in that it may control access to data structures. The difference is that access control prevents unauthorized changes while concurrency control prevents inconsistent (authorized) changes. There are two main principles a concurrency model must follow in addition to the function-independent principles of specification, grouping, automation, and performance:
d
Consistency: It must disallow inconsistent concurrent interaction. Otherwise, users are forced to manually detect and resolve inconsistencies.
d
Concurrency: It must allow consistent concurrent interaction. Otherwise, users are forced to wait unnecessarily.
Different systems put different emphasis on these principles. For instance, classical database systems emphasize the consistency principle by supporting serializable transactions19. The serializable model ensures that systems support only those concurrent transaction schedules that are equivalent to serial execution of the transactions. However, in several emerging applications, it is too conservative in that it precludes concurrent schedules that satisfy application-
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 10
specific consistency requirements20. Groupware systems, on the other hand, emphasize the concurrency and performance principles. They often take the approach of not supporting any concurrency control 17. In traditional database applications, it is difficult to imagine a scenario that does not require concurrency control, but in collaborative applications, there are situations in which no control is acceptable. If the number of collaborators is small and each user can instantly see changes made by other users to shared objects, each collaborator can be completely aware of the potentially conflicting actions of other users, and thus social protocol can prevent inconsistent changes. Experience of researchers has shown that under these two conditions few collisions occur 2, 17. In these circumstances, it is more desirable to use the computing resources to provide real-time communication of users’ changes than to check for inconsistent concurrent changes. Thus, this approach supports the concurrency and performance principles by completely sacrificing the consistency principle. If either the number of collaborators is large or the coupling is not WYSIWIS, it is useful to provide system support for ensuring consistent interaction. As with coupling, the concurrency control model must allow tailoring of the concurrency control scheme. We have identified the following set of flexibility requirements that define the kind of tailoring that should be provided:
d
Isolation: Transactions should be allowed to make a set of changes in isolation before allowing others to view them21. While the classical database systems support this requirement, few groupware systems do so.
d
Sharing of partial results: Transactions should be able to share ‘‘partial results’’ with selected sets of transactions, called their domains, before they share ‘‘final results’’ with the set of all transactions 22. This requirement is not supported by classical database systems and has been identified in the context of software engineering to allow, for example, a team of programmers to share intermediate versions of a module before they commit the final version to the testing team.
d
Hierarchy of partial results: A hierarchy of partial results, each with its domain, should be supported to capture the notion that some partial results are ‘‘more final’’ than others. For instance, it should be possible for the team of programmers to share their changes with the testers before they share them with the customers.
d
Flexible inconsistency detection time: An important issue in concurrency control is inconsistency detection time. Should the optimistic approach be used to detect inconsistencies at commit time or the pessimistic, locking-based approach be used to detect them at access time? Optimistic concurrency control has two main advantages: First, it does not lock out users from doing their work. This is important when the transactions made by users are long, since when such transactions lock data, they may cause other concurrent transactions to wait for an unacceptable time. In several collaborative situations such as group software development and writing, transactions typically span several days. Second, optimistic concurrency control does not require incremental consistency checking, thereby improving the interactive response. Its main disadvantage is that it may require users to (i) abort inconsistent changes detected at commit time, thereby losing possibly several days of work, or (ii) merge their changes, which in general is labour-intensive, even though it can be automated in some cases23. In summary, pessimistic concurrency control is desirable when inconsistent, difficult to merge changes are frequently made and optimistic concurrency control is desirable in other
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 11
situations. Therefore, a concurrency control model should allow users to choose when inconsistencies are detected.
d
Flexible lock granularity: In the design of a pessimistic concurrency control mechanism, the granularity of locking must be determined. One simple, popular approach is to support the coarse-grained, floor control, which allows only one user of a collaborative application to hold the floor at any time, locking out all other users. This form of concurrency control is suitable for lecture-style collaborations in which a single user is active at any one time. In particular, it is suitable for interaction with traditional applications supporting single-threaded dialogues, that is, dialogues that allow only one user action to be performed at any one time. For instance, it is suitable for interacting with a traditional command interpreter, which allows only one command to be input at any one time. Floor control is also application-independent and thus automatable: it is possible to build a general system such as a shared window system that manages the floor for a collaborative application, ensuring that only one user of the application can enter input at any one time. Finally, in comparison to schemes that choose finer locking granularity, it is space efficient in that it stores only one lock per application, and time inefficient in that it requires only one lock to be checked on each access. However, it is not always suitable for modern direct-manipulation user interfaces 24. These interfaces provide multi-threaded dialogues, that is, allow multiple user actions to be performed simultaneously. An example of such an interface is the spreadsheet interface, which allows multiple cells to be changed simultaneously. Providing floor control for interacting with these applications is too restrictive when users can concurrently and independently edit different cells. In this situation, it is more desirable to support fine-grained locking, which locks the edited data structures at the leaf level. Fine-grained locking, however, has two main disadvantages: First, it is not possible to provide a system that automates it unless the system can deduce the granularity of the edited data structures. Few existing applications export their structure to external agents - some of the exceptions are those developed using User Interface Management Systems (UIMS) such as Suite, which export a hierarchical representation of their data 25. Thus, it is not possible to automate fine-grained locking for most of the existing applications. Second, fine-grained locking is space inefficient in that it requires a lock for each leaf-level data item, which may be a problem if the number of displayed items is large. Sometimes, it is useful to support a compromise between fine-grained locking and floor control by supporting variable-grained locking, which allows the locking granularity for a collaborative application to change dynamically. For instance, users of a collaborative document editor may wish to start their session using floor control as each user proposes the outline of the document, then change to fine-grained control to concurrently edit different sections of the document, and finally switch back to floor control when they collectively resolve their changes. However, variable-grained control would be confusing unless the users explicitly understand the phases of their collaboration and the locking granularity supported by each phase. Variable-grained locking can also be time inefficient since locks at multiple levels may need be checked on an access. In summary, floor control, fine-grained locking, and variable-grained locking all offer important advantages and the concurrency control model should support all three of them.
Dewan, Choudhary, and Shen
d
Characterizing Collaborative Applications d 12
Flexible lock transfer: There are several alternatives for transferring locks among users. One approach is nonpreemptive transfer, wherein users keep locks until they explicitly release them. The converse approach is preemptive transfer, wherein users can unlock data locked by others. Preemptive locking reduces the wait time for locked out transactions. In particular, it avoids deadlocks and ensures that high-priority, short transactions do not have to wait for long transactions to unlock data. A disadvantage of preemptive locking is that it can lead to starvation of a user whose locks are continuously snatched by others or ‘‘lock wars’’ among users who grab locks from each other. Moreover, the data associated with a lock released by another user may have been left in an inconsistent state by the user who locked the data. A compromise is to support tickle locks 26. These locks can be released by another user if the user who has the lock has been idle for more than a certain time. They prevent starvation and ‘‘lock wars’’ but do not prevent inconsistencies in the data. Thus users should be able to choose pure preemptive, pure non-preemptive, and tickle locks.
d
Explicit and implicit transactions: Users should not be required to explicitly execute commands to group a set of commands in a transaction. The model should provide a rich set of schemes for starting and terminating transactions implicitly as side effects of editing actions, thereby reducing user overhead when these schemes are appropriate. Moreover, users should be able to override these schemes with explicit commands for grouping commands into transactions.
d
Dynamic change: As with coupling parameters, it should be possible for concurrency control parameters to be changed dynamically to allow, for instance, users of a collaborative document editor to start their session using preemptive locks as they brainstorm about the different requirements of the document and then change to nonpreemptive or tickle locks as they independently write the different parts of the document. Thus, a variety of concurrency control schemes are useful in a collaboration and the scheme to be used
depends on the application, the set of collaborators, and the phase of collaboration. In this section, we have identified some of the important issues in concurrency control for collaborative applications and motivated the need for resolving them flexibly. 4.3. Access Control Access control determines which subjects (users or programs) are authorized to do what type of operations on which objects. It is a mechanism to both protect data objects against unauthorized access and prevent mistakes by users. Research in operating systems has developed the notion of an access matrix—an abstract data structure that indicates the set of operations a subject can invoke on a protected object. Different systems provide different concrete realizations of the abstract access matrix model— some of these are low-level and emphasize flexibility while others are high-level and specify ease of use. An example of a low-level and flexible access control technique is the Hydra capability-based system27, which stores with each subject a list of capabilities. A capability is a ‘‘ticket’’ associated with a protected entity that indicates the set of operations the subject can execute on the entity. Hydra allows arbitrary capabilities to be dynamically added to a capability list, thereby supporting all possible values of the access matrix. However, a problem with the flexible approach supported by Hydra is that a capability must be explicitly defined for each object a subject has
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 13
access to. This makes the specification of access rights cumbersome and storage of them expensive since in a typical system a subject has access to a large number of objects. As a result, capability-based systems are seldom used directly— higher-level models are built on top of capability-based systems that make the specification of access rights easier and storage of them more efficient. A popular higher-level method is supported by the UNIX operating system, which makes three important simplifications to address this problem. First, it divides the set of protected objects into files and directories— smaller objects cannot be individually protected. Second, it divides the set of operations into three groups, read, write, and execute. Finally, for each protected object, it divides the set of subjects into three groups, owner, group, and others. With each protected object it associates an access list which describes the operations that can be executed by the three groups of subjects. These three simplifications allows UNIX to support the storage and specification of relatively few access right definitions. On the other hand, these simplifications make the model inflexible. For instance, they do not allow the system to support object-specific rights such as the right to annotate a document. Thus each of the two models ignores an important access control principle. What is needed is an explicit identification of principles that access control systems must meet. Saltzer28 has identified such a set based on the research done on access control in non-collaborative domains:
d
Permission rather than exclusion: The default situation should be lack of access, and the protection scheme should identify conditions under which access is permitted. In comparison to the converse approach of giving permission by default, this approach is more conservative and thus safe.
d
Total mediation: Every access to every object should be checked for correct authority.
d
No secret design: The mechanism should not depend on the ignorance of potential attackers but instead should depend on possession of specific, more easily protected, passwords or protection keys.
d
Least privilege: Every program or user should operate using the least amount of permissions required to complete the job. This principle is also called the ‘‘need to know’’ principle.
d
Ease of use: The human interface should be easy to use, otherwise users will not routinely use the protection mechanisms. Access control has also recently been studied in the context of collaboration2, 12, 29. Based on the results of
this work, several access control requirements can be formulated, some of which are lower-level, collaborationspecific requirements that can be derived from Saltzer’s general, collaboration-independent access principles. These requirements include:
d
Collaboration rights: Besides the traditional read and write operations, other operations such as coupling operations whose results can affect multiple users must be protected by a set of collaboration rights. This requirement is a corollary of Saltzer’s total mediation requirement.
d
Multiple user roles: A role is a subject that is associated with a set of privileges and responsibilities. Ellis et al2 and Patterson29 point out that role-based access specification should be supported in collaborative tools so that users’ access privileges can be inferred from the roles they take. In addition, our scenarios show that users
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 14
should be allowed to take multiple roles simultaneously. For instance, a teaching assistant should be able to simultaneously take the roles of ‘‘student’’ and ‘‘lecturer’’. This requirement can be derived from Saltzer’s ease of use principle since the concept of a role has a meaning in our daily life.
d
Object, subject, and right independence: The access control mechanism should support fine-grained specification of subjects, objects, and access rights, that is, it should allow independent specification of each access right of each subject on each object. For instance, it should allow independent specification of the access rights to each annotation in a multiuser code inspection. This requirement is a corollary of Saltzer’s least privilege requirement.
d
Object, subject, and right grouping: In several situations, these access specifications made for different objects, subjects, and rights are dependent. Therefore, the model should allow access specifications to be shared by groups of objects, subjects, and rights—a corollary of the general grouping principle.
d
Inferencing: The system should do automatic inferencing to support both consistent and easy specification of rights. In particular, the right to do an operation should imply the right to do weaker operations. For instance, the right to send partial results to a user should also imply the right to send committed results to the receiver, since the former is a stronger operation. Moreover, the rights of a subject should be inferred from the rights of less trusted subjects. For instance, rights specified for employees should be automatically given to their managers if the application semantics require the latter to have all rights of the former.
d
Flexible ownership: The model should be able to support both single-user and group ownership and allow users to specify the semantics of ownership. Traditional systems such as UNIX have shown the usefulness of single-user ownership of objects. A collaboration model should also allow multiple users to own an object together since more than one collaborator can contribute to the creation of an object and one user can create an object on behalf of a whole group. In a collaborative environment, the exact semantics of ownership may vary depending on the application. For instance, in a classroom exam scenario, the teacher should be the owner in that he should have the right to give read/write rights to the various exams. However, the ownership right should not imply write rights to the exams. On the other hand, in a code reviewing application, the owner of a comment should have all rights to the comment including both the write right and the authorizer rights.
d
Dynamic change: It should be possible to dynamically change collaboration rights, roles, owners, and ownership semantics. This requirement allows, for instance, a user of code inspection tool to graduate from an ‘‘observer’’ to an ‘‘annotator’’. It can be derived from Saltzer’s least privilege requirement since it allows subjects’ rights to change as their tasks change. Thus, like coupling and concurrency control, access control must be performed flexibly in the ways described
above while meeting the principles of easy specification, performance, and automation.
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 15
4.4. Multiuser Undo So far we have addressed elements of a multiuser ‘‘do’’ model— the operations users can perform to modify data structures, couple with other users, and specify concurrency and access control. It is crucial to also support a multiuser ‘‘undo’’ model to allow users to cancel/repeat previous actions. Undo is considered an important feature in single-user systems since it allows users to easily recover from mistakes and explore alternatives by executing competing command sequences and observing and comparing differences in the resulting system state. In a collaborative system, it is even more important to support undo. In such a system, the potential cost of an individual user’s mistake is multiplied several times because it can adversely affect the work of a large number of collaborating users. Moreover, the number of alternatives to be considered increases due to the presence of multiple users. Furthermore, a collaborative system offers new kinds of commands such as coupling-specification commands and thus provides new avenues for making errors and exploring alternatives. The notion of multiuser undo in collaborative systems is related to recovery in database systems—in both cases actions are undone in a multiuser domain. In particular, it is related to recovery of conversational transactions 30 because in both cases there is a need to undo the effect of user-interface (e.g. graphical and audio) operations. As a result, recovery mechanisms such as logging and inverse operations can be used in the implementation of multiuser undo. There is also an important difference between database recovery and multiuser undo. Database recovery deals with reversing all executed steps of incomplete, ongoing transactions (which are logically independent of each other) while multiuser undo addresses reversing selected steps of both ongoing and completed transactions. In multiuser undo, the number of undoable operations is potentially unbounded so, unlike database recovery, undo must provide a user interface for navigating through the list and selecting the operation to be undone. Moreover, in a multiuser environment, it must allow undoing of operations whose results have been observed by others. Undoing an incomplete transaction whose results have been observed by other ongoing transactions is considered undesirable in database systems because it can lead to the problem of cascaded rollbacks. However, multiuser undo/redo does not have to follow this rule since operations are allowed to see the results of previously completed operations and users are free to reverse (if possible) the effects of previously completed operations. It is presumed that a user reversing an operation has considered the results of succeeding operations before issuing the undo or do commands to achieve the reversal. Dependency checking algorithms31 can be used to help users in this situation but it is their responsibility to maintain any consistency constraints that cannot be checked by the system. It is only recently that researchers have paid attention to multiuser undo 13, 31-33. From these works several requirements for a collaborative undo model can be formulated. Some of these requirements are also relevant in the single-user case but are more important in the multiuser case:
d
Match ‘‘do’’ model characteristics: Undo should be able to perform all command reversals that are possible with forward execution of ‘‘do’’ commands. Moreover, it should always take substantially less effort to reverse actions using the undo commands than do commands that have the same effect. If this requirement is not met, then users would be forced to use forward execution to reverse actions.
Dewan, Choudhary, and Shen
d
Characterizing Collaborative Applications d 16
Unrestricted command type: It should be possible to undo all undoable commands - a corollary of the matching requirement. In particular, it should be possible to undo not only commands that edit local dispays but also those that trigger computations in the application, explicitly transmit information to other users, lock and unlock data, and change coupling, concurrency control, and access control specifications. Commands that cannot be undone should be clearly indicated and users should be asked to confirm execution of irreversible commands. Few single-user undo mechanisms meet this requirement since it is assumed that users would not want to undo ‘‘uninteresting’’ commands such as cursor movement commands, which do not change single-user state. However, in a multiuser system, fewer commands are ‘‘uninteresting’’ since commands such as cursor movement commands that do not change the local state may trigger state changes in remote displays. Thus the importance of this requirement increases in a multiuser system.
d
Undo of undo: Undo of undo is required to redo changes and is a difficult to design feature which accounts for most of the differences among current single-user undo models.
d
Unrestricted scope: Allowing undo of only the last command(s) is not enough. Often an error is not apparent until several commands have been executed. Furthermore, in a multiuser application, other users may execute commands after a user’s command, thus making it irreversible if only the last command is undoable. It is not always desirable to have a completely unrestricted scope because of the problem of undoing a command on which other commands (executed possibly by other users) depend. Schemes for detecting conflicts 31, 34 should be used and and users should be asked to confirm undoing of a command that has dependent commands. These schemes could be used to warn a user of, for instance, undo of a coupling specification if coupling enabled by the specification occurred after the specification was made.
d
Completeness: It should be possible to use undo to remove all state changes made by the command, otherwise the state of the system is not consistent. Other requirements are relevant only in the multiuser case, some of which are corollaries of the previous
requirements:
d
Flexible control: Like the do model, the undo model must provide support for flexible concurrency control. In particular, it should support both no concurrency control and turn taking mechanisms.
d
Compatibility: A multiuser undo model should behave like an existing single-user undo model when only one user is interacting with the application, thereby relieving users from learning new single-user features and allowing them to incrementally learn multiuser features.
d
Individual undo: Multiuser undo should not require intervention of all users in a collaborative session to execute an undo, since do commands do not require such intervention. This requirement allows users to participate in a collaboration without being required to synchronize their recovery commands with other users. In particular, it allows passive observers to remain synchronized with others without executing any commands themselves.
d
Remote undo: Users should be allowed to undo local commands that affect remote displays— a corollary of the matching requirement.
Dewan, Choudhary, and Shen
d
Characterizing Collaborative Applications d 17
Global undo: Users should be able to undo remote commands that affect local displays— again a corollary of the matching requirement.
d
Subgroup undo: It should be possible to undo a command for a subset of the users who saw the effect of the command, thereby restricting the exploratory phase of undo to the minimum set of users and then involving the rest only when undo is deemed to be useful. In particular, it should be possible to undo only changes to the local state. This requirement conflicts with the completeness requirement, which implies that at least two kinds of undo should be supported by the system.
d
Undo filters: It should be possible to undo commands relative to filters of the command history that contain selected commands from the history. In particular, it should be possible to undo commands relative to filters containing commands that (a) are executed by a particular user, (b) operate on a particular data structure, and (c) are of a particular type. This feature would allow a user to, for instance, create a filter that contains only the commands executed by him and then use a single undo command to undo a sequence of commands executed by him.
d
Undo independence: It is easier to design an undo mechanism if we make assumptions about how the other collaboration tasks are performed. In particular, the design is easy if we assume floor control and WYSIWIS (What You See Is What I See) coupling, since we can then assume that the users share a single command history and there are no race conditions for executing undo 13. This requirement says that the mechanism should make no such assumptions and thus be usable with arbitrary schemes for concurrency control, coupling, and other collaboration functions. Thus, in comparison to single-user undo, collaborative undo must satisfy a large and complex set of require-
ments. 5. Conclusions and Future Work This paper makes three main contributions:
d
It shows that generalized multiuser editing provides the basis for a characterization of collaborative applications that is both general and detailed.
d
It identifies four important dimensions of collaboration, coupling, concurrency control, access control, and undo; and
d
It overviews the issues, approaches, principles, and requirements for designing the collaboration functions. Further work is needed to identify other issues, approaches, principles, and requirements related to these colla-
boration functions based on more experience with designing and using collaborative applications. Moreover, our work does not identify all possible collaboration functions. For instance, it does not address ‘‘user awareness’’ — facilities for making a user aware of the meta information regarding the collaboration such as which users are involved in the collaboration and what parts of the display they are viewing or changing 35. Therefore, it would be useful to explicitly include user awareness and other collaboration functions in the model. Finally, our characterization of the design space is high-level in that it addresses ‘‘what’’ must be supported in generic editing-based
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 18
collaboration model rather than ‘‘how’’ the principles and requirements must be supported. It is possible to design a variety of useful collaboration systems that satisfy the properties identified here. We have developed one such approach that satisfies some of the editing25, coupling11, concurrency control, access control12, and undo13 properties summarized here. It would be useful to explore other approaches that satisfy these properties. Finally, it would be useful to evaluate existing collaboration systems according to how well they support the principles and requirements outlined here. This paper provides the basis for these future directions of research. 6. Acknowledgments Many thanks to Prof. Andy Whinston for inviting a paper on this topic for the Fourth Conference on Organizational Computing. This research was supported in part by National Science Foundation grants IRI-9015442 and IRI9208319 and in part by grants from the Software Engineering Research Center at Purdue University, a National Science Foundation Industry/University Cooperative Research Center (NSF Grant No. ECD-8913133). REFERENCES
1.
Ron Baecker, Readings in Groupware and Computer-Supported Cooperative Work, Morgan Kaufmann, CA (1993).
2.
Clarence A. Ellis, Simon J. Gibbs, and Gail L. Rein, Groupware: Some Issues and Experiences, CACM 34(1) pp. 38-58 (January 1991).
3.
Prasun Dewan, A Survey of Applications of CSCW Including Some in Educational Settings, Proceedings of ED-MEDIA’93, pp. 147-152 (June 1993).
4.
T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams, Dorset House Publishing Co., New York (1987).
5.
Kennith L. Kraemer and John Leslie King, Computer-Based Systems for Cooperative Work and Group Decision Making, ACM Computing Surveys 20(2)(June 1988).
6.
Prasun Dewan and John Riedl, Toward Computer-Supported Concurrent Software Engineering, IEEE Computer 26(1) pp. 17-27 (January 1993).
7.
L. C. Rosenberg, Update on National Science Funding of the ‘‘Collaboratory’’, CACM 34(12)(December 1991).
8.
Y.V. Ramana Reddy, Kanakanahalli Srinivas, V. Jagannathan, and Raghu Karinthi, Computer Support for Concurrent Engineering, IEEE Computer 26(1)(January 1993).
9.
Prasun Dewan, Tools for Implementing Multiuser User Interfaces , Trends in Software: Issue on User Interface Software 1 pp. 149-172 Wiley, (1993).
10.
Prasun Dewan and Marvin Solomon, An Approach to Support Automatic Generation of User Interfaces, ACM Transactions on Programming Languages and Systems 12(4) pp. 566-609 (October 1990).
11.
Prasun Dewan and Rajiv Choudhary, Flexible User Interface Coupling in Collaborative Systems, Proceedings of the ACM CHI’91 Conference, pp. 41-49 (April 1991).
12.
Honghai Shen and Prasun Dewan, Access Control for Collaborative Environments, Proceedings of the ACM Conference on Computer Supported Cooperative Work, pp. 51-58 (November 1992).
13.
Rajiv Choudhary and Prasun Dewan, Multi-User Undo/Redo, Technical Report SERC-TR-125-P, Software Engineering Research Center, Purdue University (August 1992).
14.
Sunil Sarin and Irene Greif, Computer-Based Real-Time Conferencing Systems, IEEE Computer 18(10) pp. 33-49 (October 1985).
15.
Gary M. Olson, Lola J. McGuffin, Eiji Kuwana, and Judith S. Olson, Designing Software for a Group’s Needs: A Functional Analysis of Synchronous Groupware, Trends in Software: Special Issue on User Interface Software, pp. 129-148 Wiley, (1993).
Dewan, Choudhary, and Shen
Characterizing Collaborative Applications d 19
16.
Thomas W. Malone and Kevin Crowston, Towards an Interdisciplinary Theory of Coordination, Tech. Report CCS TR# 120, MIT Center for Coordination Science (April 1991).
17.
Mark Stefik, Gregg Foster, Daniel G. Bobrow, Kenneth Kahn, Stan Lanning, and Lucy Suchman, Beyond the Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings, CACM 30(1) pp. 32-47 (January 1987).
18.
J.C. Lauwers and K.A. Lantz, Collaboration Awareness in Support of Collaboration Transparency: Requirements for the Next Generation of Shared Window Systems, Proceedings of ACM CHI’90, pp. 303-312 (April 1990).
19.
K.P. Eswaran, J.N. Gray, R.A. Lorie, and I.L. Traiger, The Notions of Consistency and Predicate Locks in a Database System, CACM 19(11) pp. 624-633 (Nov 1976).
20.
N.S. Barghouti and G.E. Kaiser, Concurrency Control in Advanced Database Applications, ACM Computing Surveys 23(3) pp. 269-318 (1991).
21.
Theo Haerder and Andreas Reuter, Principles of Transaction-Oriented Database Recovery, ACM Computing Surveys 15(4) pp. 287-317 (December 1983).
22.
Gail E. Kaiser, A Flexible Transaction Model for Software Engineering, Proceedings of the Sixth International Conference of Data Engineering, pp. 560-567 (February 1990).
23.
S. Horowitz, J. Prins, and T. Reps, Integrating Non-Interfering Versions of Programs, ACM Transactions on Programming Languages and Systems 11(3) pp. 345-387 (July 1989).
24.
Ben Shneiderman, Direct Manipulation: A Step Beyond Programming Languages, IEEE Computer 16(8) pp. 57-69 (Aug 1983).
25.
Prasun Dewan and Rajiv Choudhary, A High-Level and Flexible Framework for Implementing Multiuser User Interfaces, ACM Transactions on Information Systems 10(4) pp. 345-380 (October 1992).
26.
Irene Greif, Robert Seliger, and William Weihl, Atomic Data Abstractions in a Distributed Collaborative Editing System, Conference record of POPL, (January 1986).
27.
W. Wulf, E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, and F. Pollack, Hydra: The Kernel of a Multiprocessor Operating System, CACM 17(6)(June 1974).
28.
J.H. Saltzer, Protection and the control of information sharing in multics, Communications of the ACM 17(7) pp. 388-402 (July 1974).
29.
John F. Patterson, Ralph D. Hill, Steven L. Rohall, and W. Scott Meeks, Rendezvous: An Architecture for Synchronous Multi-User Applications, Proceedings of the Conference on Computer-Supported Cooperative Work, pp. 317-328 (October 1990).
30.
R. Pausch, Adding Input and Output to the Transactional Model, Ph.D. Thesis and Technical Report Number CMU-CS-88-171, Carnegie Mellon University, Department of Computer Science (August 1988).
31.
Atul Prakash and Michael J. Knister, Undoing Actions in Collaborative Work, Proceedings of the ACM Conference on Computer Supported Cooperative Work, pp. 273-280 (November 1992).
32.
James Rhyne and Catherine Wolf, Tools for Supporting the Collaborative Process, Proceedings of Conference on User Interface Systems and Technology, pp. 161-170 (1992).
33.
Thomas Berlage and Andreas Genau, A Framework for Shared Applications with Replicated Architecture, Proceedings of Conference on User Interface Systems and Technology, (to appear in November 1993).
34.
W.D. Elliot, W.A. Potas, and A. van Dam, Computer assisted tracing of text evolution., Proc. of AFIPS Fall Joint Computer Conf, pp. 533-540 (1971).
35.
Michel Beaudoin-Lafon and Alain Karsenty, Transparency and Awareness in a Real-Time Groupware System, Proceedings of UIST’92, (1992).
