Coupling the User Interfaces of a Multiuser Program - CiteSeerX

Coupling the User Interfaces of a Multiuser Program PRASUN DEWAN University of North Carolina at Chapel Hill RAJIV CHOUDHARY Intel Corporation 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 We have developed a new model for coupling the user-interfaces of a multiuser program. It is based on an interaction model and a user-interface framework that allow users and programmers, respectively, to view applications as editors of data. It consists of a semantics model, a specification model, and an implementation model for coupling. The semantics model determines which properties of interaction entities created for a user are shared with corresponding interaction entities created for other users and when changes made by a user to a property of an interaction entity are communicated to other users sharing it. It divides the properties of an interaction entity into multiple coupling sets and allows users to share different coupling sets independently. It supports several criteria for choosing when a change made by a user to a shared property is communicated to other users including how structurally complete the change is, how correct it is, and the time at which it was made. The specification model determines how users specify the desired semantics of coupling. It associates interaction entities with inheritable coupling attributes, allows multiple users to specify values of these attributes, and does a runtime matching of the coupling attributes specified by different users to derive the coupling among their user-interfaces. The implementation model determines how multiuser programs implement user-customizable coupling. It divides the task of implementing the coupling between system-provided modules and application programs. The former automatically support a predefined semantic and specification model which can be extended by the latter. We have implemented the coupling model as part of a system called Suite. This paper describes and motivates the model using the concrete example of Suite, discusses how aspects of it can be implemented in other systems, compares it with related work, discusses its shortcomings, and suggests directions for future work. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Systems—distributed applications, distributed databases; D.2.2 [Software Engineering]: Tools and Techniques—user interfaces; D.2.6 [Software Engineering]: Programming Environments—interactive; D.3.3 [Programming Languages]: Language Constructs—input/output; H.1.2 [Models and Principles]: User/Machine Systems—human factors; H.4.1 [Information Systems Applications]: Office Automation; I.7.2 [Text Processing]: Text Editing General Terms: Design, Human Factors, Languages Additional Key Words and Phrases: collaboration, computer supported cooperative work, groupware, structure editors, user interface management systems

3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333

3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 First Author’s address: Department of Computer Science, University of North Carolina, Chapel Hill, N.C. 27599. Second Author’s address: Mail Stop HF3-02 Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, Oregon 97124. 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).

P. Dewan and R. Choudhary

Coupling User Interfaces d 2

1. Introduction A multiuser program creates multiple user-interfaces allowing multiple users, possibly geographically dispersed, to interact with the program. To allow its users to collaborate with each other, the program must couple its user-interfaces, that is, allow these interfaces to share state. Three important issues raised by the necessity to couple the user-interfaces of a multiuser program are:

d

Semantics: In what ways should users of a multiuser program be able to couple their user-interfaces?

d

Specification: How should users of a multiuser program choose the coupling among their user interfaces?

d

Implementation: How should developers of a multiuser program implement the desired coupling semantics and specification scheme? In general, a complete set of answers to these questions will depend on application semantics. Nonetheless, it

is useful to develop a coupling model that identifies generic answers to these questions. The nature of such a model is the focus of this paper. It is important to develop a coupling model that supports flexibility, ease-of-specification, and ease-ofimplementation. A restrictive coupling model that requires, for instance, that all users share the complete interaction state will be unusable by users who wish to create both public and private information. On the other hand, a flexible coupling model will be difficult to use if the model makes it non-trivial for users to specify the desired coupling. For instance, a coupling model that supports both public and private state will be difficult to use if it requires users to name each unit of the public state. Similarly, a multiuser program will be difficult to implement if the model offers only low-level support for implementing the desired coupling semantics and specification scheme. Several previous systems (surveyed in § 6) have addressed the issue of coupling but none of them has been designed to meet all three requirements. While previous systems offer different couplings, none of them offers multiple couplings. For instance, traditional transaction systems allow users to share only committed changes and require them to explicitly store and retrieve shared values, while real-time collaboration tools allow users to share incremental changes and automatically inform users of changes made by other users. However, no system supports both methods of coupling user interfaces. Moreover, none of the previous systems offers both flexibility and ease of programming. For instance, distributed object systems provide flexible but low-level implementation support that allows programmers to define arbitrary coupling semantics and specification schemes while shared window systems offer automatic support for a restricted coupling model that requires all users of a program to share a single interaction state. Finally, previous works have not addressed specification of coupling since since they support fixed, hard-wired couplings. We have developed a new coupling model designed to meet all three requirements. The model is based on an interaction model and a user-interface framework that allow users and application programmers, respectively, to view programs as editable data. It consists of new semantics, specification, and implementation models for coupling. The



semantics model divides the properties of an interaction entity 1 into multiple coupling sets and allows users to share different coupling sets independently. It supports several criteria for choosing when a change made by a user to a shared property is communicated to other users including how structurally complete the change is, how correct it is, and the time at which it was made. The specification model associates interaction entities with inheritable coupling attributes, allows multiple users to specify values of these attributes, and does a runtime matching of the coupling attributes specified by different users to derive the coupling among their user-interfaces. It includes a user-interface that allows users to interactively change the coupling. Finally, the implementation model provides automatic support for the predefined semantics and specification models and allows application programs to extend these models. We have implemented the coupling model as part of a system called Suite [10]. This paper discusses the model using the concrete example of Suite. A previous conference paper [11] briefly discusses a preliminary version of the coupling model and a conference video publication [13] briefly illustrates the model. The rest of the paper is organized as follows. Section 2 outlines the interaction model and user-interface framework used as the bases for the coupling model. Section 3 is the main part of the paper. It motivates, describes, and illustrates the various components of the coupling model. Section 4 addresses the implementation of the model and Section 5 describes some example coupling policies supported by the model. Section 6 compares the coupling model with related work, Section 7 discusses how it can be supported in systems other than Suite, and finally, Section 8 gives conclusions and discusses potential directions for future work. 2. Bases: Interaction Model and User-Interface Framework As mentioned in the previous section, coupling allows the user interfaces created for different users of a program to share state. The nature of the state maintained by each of these user-interfaces can be defined at various levels of abstraction. For instance, it can be defined as a screen bitmap, a set of windows, or a set of widgets. We refer to a model describing the nature of this state as an interaction model. The design of semantics and specification models for coupling depend on the nature of the interaction model they are based on— as we shall see in § 7, the higher the abstraction of the interaction model, the more flexible and high-level these models can be. Similarly, a user-interface can be implemented using a a variety of user-interface frameworks. For instance, it can be implemented using a window system or toolkit. The design of an implementation model for coupling userinterfaces depends on the framework used to implement the user-interfaces. As we shall also see in § 7, the higher the abstractions supported by the framework, the more automation the implementation model can offer. We have used the generalized editing model and the Suite user-interface framework [14] as the bases for our coupling model. The generalized editing model allows a users to view programs as active data that can be edited to trigger computations. The interaction entities offered by the model include interaction variables, attributes, value groups, and several windows for inputting commands and displaying results and error messages. These windows include object windows, which display interaction variables; menu windows, which are used to input commands; error 333333333333333333 1

By an interaction entity we mean a unit of the interaction state created by an interactive program.



windows, which display error messages, and attribute windows, which are used to specify values of attributes. An interaction variable is a program data structure displayed to the user. It can be updated by the program to show results and edited by the user to input new values. Once a user has changed a set of interaction variables, he can execute the commit command to send the new values of these variables to the program. An attribute is an interaction property of an interaction variable, which can determine, for instance, the presentation of the variable or the callbacks invoked when the variable is edited by the user. A value group is a group of related interaction variables that stores attributes shared by these variables. Attributes of interaction variables and value groups can be changed dynamically both by the program and its users. A multiple-inheritance relation is defined among value groups, which allows a more specific value group to inherit attributes from more general ones. We illustrate the interaction model using the example of a Suite program, called example, that allows a user to view and manipulate a budget. The program maintains a list of budget items and allows a user to add new items and change the amount spent for an item. We will use this program as a running example to illustrate the various components of the coupling model. Figure 1 shows three users, users A, B, and C, interacting with the program. As shown in the Figure, for each user, the program creates an object window, which displays a structured interaction variable, called budget, consisting of several fields: an item template, a list of committed items, and the total amounts available, allocated, and spent, respectively. The template can be edited to enter a new item in the list and the item list itself can be edited to change the money spent for an item. These data structures can be manipulated independently by the three users, as shown in Figure 1. These interaction variables are grouped into various value groups. For instance, all elements of the item list of the budget are grouped into the value group budget.items child. A separate version of the value group is created for each user, which groups the budget elements created for that user. Each of the value groups is associated with its own set of attributes, which are inherited by its members. The coupling model described below allows these interaction entities to exchange state, thereby allowing the users to collaborate with each other.

Figure 1: Three Users Independently Manipulating the Template



These interaction entities are managed by the Suite framework, which provides an application and its users with a high-level programming and user interface, respectively, to manipulate interaction entities. Thus application programmers are relieved of the task of implementing the user-interfaces of applications. The semantic and specification components of our coupling model extend the generalized editing model by allowing the interaction entities created for different users of an application to flexibly exchange state. The implementation component of the model extends the Suite framework by automating the implementation of coupling semantics and specification. In the remainder of the paper, we describe these components in detail. 3. The Suite Coupling Model A simple approach to defining a coupling model is to support a single coupling for all users and programs. However, this approach is too restrictive, for several reasons: Variety of Multiuser Programs: Different multiuser programs may have very different coupling needs. For instance, a multiuser debugger may wish to display the same image of a single shared state on all workstations, thereby allowing each user to see the cause-effect relationships, while a multiuser program editor may wish to allow different users to see different views of the program. Similarly, a multiuser ‘‘talk’’ program may wish to transmit a user’s change to other users as soon as it is made, while a ‘‘mail’’ program may wish to delay the transmission until the user explicitly executes a command to send the data. The notion of flexible coupling is crucial for developing a general-purpose system for implementing multiuser programs. Variety of Phases: Sometimes it is useful to couple a shared data structure displayed by a multiuser program differently at different times during the lifetime of the program. For instance, during the ‘‘outline phase’’ of a 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 phase’’, they may wish to again see a change as soon as it is made. Minimum Performance Levels: The response time of multiuser programs depends on the kind of coupling among its user-interfaces— 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 circuit module created by a user of a multiuser circuit 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. Variety of Roles: Different users interacting with a multiuser application may have different roles and thus may wish their displays to be coupled differently. For instance, a programming-language tutor interacting with a multiuser program editor may wish to see raw values input by beginner 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. Similarly, managers using a



multiuser budget editor to balance a budget may wish to see uncommitted changes to the budget (so that they can agree on a change before they commit it) but may wish their employees to see only committed changes. For these reasons, the Suite coupling model does not support a single, fixed coupling. It provides two kinds of mechanisms to flexibly couple the interaction entities created for different users of a multiuser program:

d

Parameterized, Peer-to-Peer Coupling: It defines peer relationships among the interaction entities created for different users. Interaction entities that are peers of each other are different versions created by different users of a single logical entity. Thus, in the example above, the Allocated fields of the budget templates of the users A, B, and C, are considered peers of each other, and the two windows created for the two users are also considered peers of each other. Suite automatically couples peers based on values of coupling parameters. These parameters determine (a) whether a change made to an interaction entity is to be shared with a peer of the interaction entity and (b) if the change is to be shared, when it is be reflected in the latter. Thus, they determine, for instance, whether a change made to the value of the Allocated field of the budget template of user A is to be shared with the corresponding field of the budget template of user B, and if is to be shared, when the change is to be reflected in the latter. Suite defines default values of these parameters and provides application programs and their users high-level mechanisms for dynamically changing these values.

d

Programmed Coupling: Suite also supports Suite callbacks, which allow the application program to respond to arbitrary editing commands, and Suite calls, which allow the program to update arbitrary interaction entities. The application program can use Suite callbacks and calls to couple interaction entities of different users in arbitrary ways. For instance, it can respond to a change made to the value of name field of a budget item of user A by changing the selection attribute of the Allocated field of the budget item of user B, thereby prompting the latter to enter the value for this field. Suite calls and callbacks are explained in detail in [14]. Therefore, in this paper will focus only on the model

provided by Suite to support peer-to-peer coupling. We will refer to this model as the Suite coupling model. The Suite coupling parameters define a coupling space, where each point in the space defines a coupling that can be dynamically selected by an application or its users. We used an iterative approach to the selection of the coupling parameters. In an initial implementation of the coupling model, we supported a small set of coupling parameters since at that time we did not fully understand the various aspects of coupling and believed that users would want to control only a few of them. However, on using the system and better understanding the various dimensions of coupling, we felt the need for more flexibility. Therefore, we redesigned the coupling model based on our experience with the initial implementation and scenarios of interaction with a variety of multiuser programs including multiuser talk programs, debuggers, program demonstrators, circuit editors, program editors, and spreadsheets. We tried to associate coupling parameters only with those aspects of coupling that users would want to control. Thus every coupling parameter has been designed to support either a real scenario we faced or a potential scenario we identified.


P. Dewan and R. Choudhary 3.1. Coupling Principles

A flexible coupling model must make several decisions regarding the semantics, specification, and implementation of coupling. How these decisions are made is influenced by the coupling principles the model has been designed to support. The Suite coupling model has been designed to support the following coupling principles: Data Independence: The coupling model should allow different interaction entities displayed to a user to be coupled differently with their counterparts displayed to another user. For instance, it should allow the coupling between user A’s and B’s versions of interaction entities I1 to be different from the coupling between their versions of I2, as illustrated by different settings of the ‘‘coupling dials’’ of Figure 2. 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 paper references and private comments on these papers. User Independence: The model should allow an interaction entity to be coupled differently with different peers created for different users (Figure 3). User independence is required to support a variety of user roles such as the ‘‘tutor’’ and ‘‘student’’ roles discussed earlier.

I1

I1

I2

I2

User A

User B

Figure 2: Data Independence User A

User B

I1

I1

I1 User C

Figure 3: User Independence



Flexible Sharing: The model should allow independent sharing of semantic, viewing, formatting, access, and selection properties of a pair of interaction entities. This principle is required to support, for instance, the ‘‘program editor’’ example of the previous section, which allows users to share semantic properties of programs without sharing their viewing properties. Scenarios to motivate independent sharing of other properties are given in § 3.3, which defines these properties in the context of Suite. Flexible Communication: It should be possible to choose when a change to a property of an interaction entity is communicated to the peers of the entity sharing the property based on whether related entities have been changed, the changed property has been validated to the desired level, and sufficient time has elapsed since the change was made. Flexible communication is required to support multiple phases and minimum performance levels discussed in the previous section. Other scenarios to motivate this principle are given in § 3.4, which describes the exact set of conditions in Suite that trigger communication of changes to shared properties. Individual Specification: One approach to the specification of coupling is to require direct specification of the coupling parameters. Each pair of users would specify the values of the coupling parameters for the pairs of corresponding interaction entities created for them. To illustrate this approach, assume that the parameters P1, P2, P3 determine the coupling between each pair of interaction entities (Figure 4). Users A and B would directly specify the values of of these parameters for the two versions of the interaction entity I1 after agreeing on these values. This approach makes it easy to support data- and user- independence since it allows independent tailoring of the coupling between each pair of peer interaction entities. However, it makes the overhead of collaborating with other users high since users must agree on the values of the coupling parameters of pairs of corresponding interaction entities displayed to them. Therefore, the coupling model should support an indirect approach to specification of coupling that allows users to independently specify how they would like the interaction entities displayed to them to be coupled with corresponding entities displayed to other users. The values of the coupling parameters of a pair of corresponding interaction entities displayed to two users should be automatically derived by matching the coupling preferences C1

C2

C3

C1

C2

P1

P2 I1

I1 P3

User A

User B

Figure 4: Individual Specification

C3



specified by these users. Continuing with the example of Figure 4, this approach allows users A and B to independently set the values of the coupling preferences C1, C2, C3 regarding their versions of the interaction entity I1, which indirectly determine the values of the coupling parameters between these versions. § 3.2 describes how these preferences are represented in Suite. Conservative Matching: Individual specification allows two users to make different coupling specifications regarding how their interaction entities are to be coupled. In such situations, the system should take the conservative approach to matching different coupling preferences, that is, it should choose the coarser granularity of sharing and communication specified by the two users, thereby giving users control over which properties of their interaction entities are shared with others and when changes to these properties are transmitted to/received from others. § 3.3 and 3.4 describe and motivate the exact rules used by the model to match different sharing and communication specifications, respectively. Reuse: The model should allow a specification of a coupling preference to be reused for different interaction entities of a user, for different peers of an interaction entity, and by different users of a multiuser application. § 3.2 and 3.5 describe how this principle is supported in Suite. Automation and Extensibility: The system should automatically support the coupling semantics and specification models and allow an application to tailor them. § 3.6 discusses how Suite meets this principle. 3.2. Coupling Attributes In accordance with the principle of individual specification, the Suite coupling model does not require the direct specification of the parameters of coupling between a pair of interaction entities. Instead, it requires the specification of coupling attributes, which are associated with individual interaction entities. Each coupling attribute indicates a user’s preference regarding some parameter of the coupling between the interaction entity and the interaction entities created for a group of users. For instance, user A can specify the value (True, suite) for the ValueCoupled attribute (defined in § 3.3) of an interaction variable to indicate that he would like the semantic properties of the interaction entity to be shared with the corresponding interaction entities created for users in the group suite. The mechanisms provided for defining user groups in Suite are described in [14]. These groups can contain arbitrary sets of users including specific users and all other users. By allowing specific users in the definitions of coupling attributes, Suite supports the user-independence principle, since an interaction entity can be coupled differently with each of its peers. By allowing groups of users in the definitions, it supports the reuse principle, since it allows a coupling specification to be reused for different peers of an interaction entity. Suite allows a user to make multiple definitions of a coupling attribute with different values for the group field. For instance, it allows user A to make the additional definition, (False, others), for the ValueCoupled attribute of the interaction variable. In case of conflicts, Suite chooses the value associated with the most specific group. Thus, in this example, it chooses the first definition of of ValueCoupled for a member of the group suite, since suite is a more specific group than others.



The exact set of coupling attributes are given below. In the remaining discussion, we will omit the group field of the value of a coupling attribute of an interaction entity when discussing the coupling of the entity with a specific peer. Thus, when discussing the coupling between two interaction variables created for users A and B, respectively, if we say that the ValueCoupled attribute of the former variable is False, we strictly mean that among all definitions of the ValueCoupled attribute whose second fields name groups containing B, False is the value associated with the most specific of these groups. 3.3. Sharing of Properties Suite divides the properties of each interaction entity displayed to a user into several disjoint coupling sets and associates a coupling set with a boolean sharing attribute, which determines if the properties in the set are shared with the corresponding interaction entities displayed to other users. Like values of other coupling attributes, values of sharing attributes are considered by the system to be ‘‘hints’’ given by users regarding sharing of properties of the interaction entities displayed to them. Suite uses the following rule to determine which properties of a pair of corresponding interaction entities are shared: Sharing Rule: The properties in a coupling set are shared between a pair of corresponding interaction entities iff the associated sharing attribute of both of these entities has been set to True. An alternative rule is to share a set of properties of a pair of corresponding entities if the associated sharing attribute of either of these entities has been set to True. We chose the former because it gives users control over which properties of their local interaction entities are shared with others. The converse approach would allow a user to share/update the interaction state of another user against the wishes of the latter. This approach can be simulated in Suite if users have explicitly set the value of the CouplingCoupled attribute, discussed in § 3.5. We describe below the sharing attributes and coupling sets currently supported in Suite. The ValueCoupled sharing attribute of an interaction variable determines whether the value of the variable is shared with corresponding interaction variables. To illustrate its role, consider the example template. Should changes made to the template by user A be seen by other users such as B and C? The answer depends on the level of collaboration between the users. If two users are working together to add a new item, then changes made to the template by one of them should be communicated to the other. On the other hand, if they are independently adding items, then they should not share changes to the data structure. The ValueCoupled attribute allows them to decide whether the values of the two templates are shared or private. Since this attribute is associated with each interaction variable, users A and C can share changes to the list of items but not the item template, as illustrated by Figure 5, which shows the windows of users A, B, and C. The coupling set associated with the ValueCoupled attribute contains not only the value of the variable but also the Uninitialized and Erroneous attributes of the interaction variable. The Uninitialized attribute determines whether the variable has been initialized—if the variable is uninitialized then Suite displays a placeholder for it, as illustrated by the window of user C (Figure 5), which contains an uninitialized value for the Allocated field of the template. The Erroneous attribute determines whether the value of the variable is



Figure 5: Dimensions of Sharing. The templates of A and C are different since they are not value coupled. Items that are elided in A’s display are also elided in B’s display since they are view coupled. The elided views of the rent items in A’s and C’s display are presented differently since they are not format coupled. The windows of A and C show the same data on the first line since they are scroll coupled. The Available fields of all three users are selected since they are selection coupled. The coupling windows in Figure 10 show how some of these couplings were specified. erroneous—if the value is erroneous an error message is displayed in the error window, as illustrated by the error windows of the users A and B (Figure 5), which describe the error in the shared Allocated field of the template. We include these attributes of an interaction variable in the ValueCoupled coupling set since they are closely related to the value of the variable— together with the value of a variable they define its semantic state. It is possible to create multiple views of a variable showing different parts of it. In Suite, the view attributes of a variable determine which parts of the variable are displayed. Currently, Suite supports only one view attribute, Elided, which determines if the components of the value are displayed or hidden. In the future, we plan to support additional view attributes that select the components of a value that are displayed. The ViewCoupled attribute of an interaction variable determines whether its view attributes are shared with corresponding interaction variables. Figure 5 illustrates view coupling in Suite. The views of the elements of the item list displayed to user A are coupled with the corresponding views displayed to user B but not user C. As a result, when A executed the Elide command to ‘‘elide’’ the first two elements of the item list, the elements were elided in both windows. View coupling allows users to refer to data structures in terms of their views in addition to their values. For instance, users A and B can refer to the third item of the item list as the ‘‘unelided item’’. A view of an interaction variable may be formatted in different ways. For instance, the ‘‘elided presentation’’ of the first item of the item list can be or . Suite associates an interaction variable with a set of format attributes, which determine how its views are formatted. An example of a format attribute is the ElideString attribute, which determines the elided presentation of the variable. The FormatCoupled attribute of an interaction variable determines whether the formatting properties of the variable are shared with corresponding interaction variables. Figure 5 illustrates format coupling in Suite. User A shares the formatting properties such as ElideString of the elements of the item list with user B but not with user C. Format coupling allows users to define formats for others. In addition, it allows them to refer to data structures in terms of their presentations in



addition to their views and values. For instance, it allows users (interacting from colour screens) to refer to the ‘‘red item’’. Access attributes of an interaction variable determine the set of commands a user can execute on a variable and include the Selectable, ReadOnly, and other attributes described in [32]. The AccessCoupled attribute of an interaction variable determines whether the access attributes of the variable are shared with corresponding interaction variables. The SelectionCoupled attribute of an interaction variable determines whether the selected property of the variable is shared with corresponding interaction variables. Selection coupling can be used, for instance, by user A to draw the attention of user B and C to the Total Available field (Figure 5). Suite also allows coupling of properties of corresponding windows created for different users. Each window displayed to a user is associated with the ScrollCoupled sharing attribute, which determines whether the scrollbar of the window is coupled with scrollbars of the peers of the window. Scroll coupling, as reported in [33], can lead to ‘‘scroll wars’’ when users want to independently browse through a document. However, it is useful, for instance, when a user is demonstrating the user interface of an application to other users or a group of users are together browsing through some document. In Suite, when two windows are scroll coupled, the first lines of these windows display the first lines of presentations of interaction variables that are peers of each other, as shown in Figure 5, where the object windows of users A and C are scroll coupled. Thus, we support linking of data or semantics during coupled scrolling rather than linking of syntax. 2 Linking of syntax is not always possible in Suite since two windows that are scroll coupled, such as the windows of users A and C, may show different presentations of interaction variables. Thus, it is possible for views and formats of variables displayed in a window to be coupled without the scrollbars of these windows being coupled, and vice versa, thereby allowing, for instance, (i) A and B to see the same presentations of interaction variables (such as the item list) but different parts of these presentations and (ii) A and C to see the same interaction variables but different views and presentations of these variables. Suite also associates each window with an ActionCoupled attribute, which determines whether actions performed in that window for invoking commands are coupled. For instance, if the ActionCoupled attributes of the menu windows of A and B are set to True, then if A clicks on the Elide button in his menu window, the button is highlighted in the menu windows of both A and B and the Elide command in executed for both users. We allow these couplings to be controlled separately since users may want scroll coupling without action coupling. For instance, users browsing through a document together may want scroll coupling but not action coupling. So far, we do not know of a scenario in which users may want action coupling without scroll coupling. To support group demonstrations, Suite allows coupling of several other properties of shared windows including their position and size.

333333333333333333 2

If the coupling policy supported is syntax coupling (see § 5), then there is no difference between linking of semantics and syntax during shared scrolling.



3.4. Communicating Changes to Shared Properties When should a change to a shared property made by a user be communicated to other users? Let us first consider the value of an interaction variable. 3.4.1. Communicating Changes to Values By default Suite communicates changes to values of interaction variables to other users when they are committed. Sometimes, however, a user may wish to consult other users about a changed value before committing it. Therefore, like talk programs and shared window systems, Suite also supports communication of every change to a shared value as soon as it is made, thereby supporting sharing of uncommitted values or ‘‘partial results’’ [19]. These two approaches represent two extreme methods for communicating changes to shared properties. Often users want middle grounds between communicating changes when they are committed and communicating them as they are made. Therefore, Suite also allows users to choose several intermediate methods of communicating changes. It allows users to specify different criteria for transmitting changes made by them and receiving those made by others, thereby allowing, for instance, ‘‘shy’’ users to receive incremental changes made by others but transmit only committed changes made by them and ‘‘busy’’ users to transmit incremental changes made by them but receive only committed changes made by others. It supports the following criteria for selecting the communication method: User Operations: It defines a set of user operations on interaction variables that can trigger communication of changes to the values of these variables to other users and allows both the transmitting and receiving users to choose which of these operations trigger communication of these changes. These operations include Increment, which is executed by a user to make an ‘‘incremental’’ change to the data structure, Complete, which is executed by a user to indicate ‘‘completion’’ of a series of incremental changes to the data structure, and Transmit, which is executed by a user to explicitly demand transmission of changes to the data structure. These three operations are abstract operations and must be mapped to concrete commands provided by the editor used to modify the presentation of the data structure. Suite currently provides two editors, a text-editor for editing textual presentations of data structures and a bar editor for editing presentations of data structures represented as bars. In the case of the text editor, insertion or deletion of a character in the presentation of a data structure is considered invocation of the Increment operation, and movement of the insertion point away from the presentation of the changed data structure is considered execution of the Complete abstract operation. In the case of the bar editor, ‘‘dragging’’ the bar is considered execution of the Increment operation and ‘‘releasing’’ the bar is considered execution of the Complete operation. In either case, clicking on the Transmit menu button is considered execution of the Transmit operation. A user may wish to complete a series of changes to the fields of a structured interaction variable before communicating these changes to others. For instance, user A may wish to communicate a series of changes to the fields of the item template when he moves the cursor away from the complete template and not as he moves it away from each changed field. Suite provides the CompletionUnit boolean attribute to allow users to choose the scope of completion— a complete operation on an interaction variable triggers communication of changes to it only if its



CompletionUnit attribute is True. Thus user A can achieve the coupling above by setting the CompletionUnit attribute of the template to True and each of the fields of the template to False. Time-based Communication: Suite also allows users to request periodic communication of changes with periods specified by them, thereby allowing, for instance, users collaborating on a software design to automatically exchange changes at the end of each day. Similarly, it allows users to request communication of changes at a particular time, thereby allowing, for instance, code inspectors to automatically receive changes made by programmers at the times inspection meetings take place. It allows the value of a variable to be transmitted to other users at the start of each of its transmission periods or at its transmission time. Similarly, it allows new values received for an interaction variable to be displayed at each of its listening periods or at its listening time. Suite invokes the TPeriod ( LPeriod ) system operation on the variable at the start of each of its transmission (listening) periods and the TTime ( LTime ) system operation on the variable when the current time becomes equal to its transmission (listen) time. Correctness of Communicated Changes: Suite allows (transmitting and receiving) users to specify the correctness of values exchanged among them, thereby supporting, for instance, the ‘‘tutor-student’’ example presented earlier. The communication correctness levels include Raw, Parsed, Validated, and Committed, which are associated with values that have been changed, checked for syntax errors, checked for semantic errors, and committed, respectively. In Suite, a committed value is guaranteed to be free of semantic errors and a value free of semantic errors is guaranteed to be free of syntax errors [9]. Suite defines two attributes, called feedback attributes, which determine when a value is checked for syntactic correctness, semantic correctness, and committed [9]. We describe below communication attributes and communication rules that allow the coupling model to support all of the communication criteria described above. Transmitting Changes Consider first the criteria used by users to determine when changes made by them are transmitted to other users. One method for accommodating all of these criteria is to define for each of them a Boolean attribute that determines whether the criterion is to be used for transmitting changes to the interaction variable. For instance, it is possible to associate an interaction variable with the TransmitOnIncrement and TransmitOnPeriod attributes determining whether values of the variable should be transmitted on the Increment and TPeriod operations on the variable; and the TransmitOnParsing and TransmitOnValidation attributes determining whether parsed and validated values of the variable should be transmitted. This approach is general since it allows a user to select each criterion independently. On the other hand, it also requires a large number of coupling attributes. We have simplified the approach using two observations and assumptions. The observations are: (1)

A value of a variable that is guaranteed to have a certain correctness level is also guaranteed to have lower correctness levels. For instance, a validated value of a variable is guaranteed to be parsed. As a result, it is not necessary to define a separate Boolean attribute for each of the correctness levels—it is sufficient to define a single attribute that indicates the minimum correctness a transmitted value should have.

P. Dewan and R. Choudhary (2)


By transmitting incremental changes to a variable a user transmits all changes to the variable. As a result, it is not necessary, for instance, to define separate attributes for sending incremental changes and completed changes to a variable since sending the former implies sending the latter.

The assumptions are: (1)

A Complete operation is executed on a changed value before a TPeriod operation is executed on it, and the latter is executed on the value before the TTime operation is executed on it. We make this assumption because we expect the Complete operation to be executed on a changed value within a few minutes, the TPeriod operation within a few hours, and the TTime operation within a few days. This assumption implies that it is not necessary to send periodic (timed) changes if completed (periodic) changes are being sent.

(2)

Users always wish to communicate changes on execution of the Transmit operation (as long the value meets the correctness criterion) since this operation is explicitly executed by them to request transmission of changes. Thus it is not necessary to associate this operation with a transmission attribute.

We can now define our scheme for transmitting values. Users specify their preferences regarding transmission of values of changed interaction variables by defining values of the transmission attributes of these variables. Suite associates each interaction variable with four transmission attributes, TransmissionPeriod, TransmissionTime, TransmitOn, and TransmissionCorrectness. The TransmissionPeriod and TransmissionTime attributes specify the transmission period and time, respectively, of the interaction variable. The TransmitOn and TransmissionCorrectness attributes specify which communication operations executed on an active variable trigger transmission of changed values and how correct these values must be before they are transmitted. Communication operations include the Increment, Complete, and Transmit user operations, and the TPeriod and TTime system operations. Suite defines the following orders on the communication operations and correctness levels. Increment < Complete < TPeriod < TTime < Transmit Raw < Parsed < Validated < Committed It uses these orders in the following transmission rule: Transmission Rule: The value of a changed variable is always transmitted when it is committed. In addition, the value is transmitted on execution of any communication operation on the variable that is equal to or greater than the value of its TransmitOn attribute if the correctness of the value is greater than or equal to the value of its TransmissionCorrectness attribute. This simple rule supports all of the transmission criteria described above. Receiving and Installing Changes Our approach to receiving values from other users is a dual of our approach to transmitting values. Users specify their preferences regarding receiving values of changed variables by defining values of the listening attributes, ListenOn and ListeningCorrectness, which take the same values as their transmission counterparts. Suite



uses the following rule for determining which values of changed variables are received: Receiving Rule: The value of a changed variable is always received when it is committed. In addition it is also received if its transmission was caused by the execution of a communication operation equal to or greater than the value of the ListenOn attribute of the (receiving) variable and the correctness of the variable is greater than or equal to the value of the ListeningCorrectness attribute of the variable. The transmission and receiving rules allow both the transmitter and receiver to determine which communication operations trigger communication of changed values and how correct these values must be before they are communicated. However, they do not allow the receivers to influence the times at which changes made by other users are made visible to them. For instance, they do not allow receivers to request that they view other users’ changes at the end of each day. To overcome this limitation, Suite does not immediately display a new value received for an interaction variable to the user listening for it. Instead, it stores the value in a receive buffer associated with the variable, which always holds the latest value received for the variable. The value of the receive buffer is assigned to the interaction variable when it is installed by the system. Separating the notions of receiving and installing values allows listening users to influence the times at which received values are displayed to them. They specify their preferences regarding the times at which received values should be installed by defining values of the listening attributes, ListeningPeriod and ListeningTime. Suite uses the following rule for installing received values: Installation Rule: The installation of a value received for an interaction variable depends on the ListeningPeriod and ListeningTime attributes of the variable. The value is installed at the earlier of the listen time and the start of the next listening period of the variable. The value is installed immediately if either of these attributes has the value ListenNow. Users can explicitly install received values by executing the Listen command. To illustrate our communication model, consider the fields of the item template. Assume that user A has set the TransmitOn and TransmissionCorrectness attributes of these fields to Increment and Raw, respectively. Assume also that user B has set the values of the ListenOn and ListeningCorrectness attributes of these fields to Transmit and Raw, respectively, and user C has set their values to LPeriod and Validated, respectively. Finally, assume that user B has set the values of the ListeningPeriod attributes of these fields to ListenNow and user C has set them to an hour. Figure 6 shows what happens when user A inputs a new erroneous value for the template. This value is not received immediately by user B or C. Figure 7 shows what happens when user A executes the Transmit command to transmit the template. This ‘‘partial result’’ is displayed to B but not C, who is receiving only validated values and not installing them immediately. Notice that the item list has not yet been updated by the underlying application since the new template has not been committed. Either user A or B can now correct the mistake. Within an hour after the value is corrected it will be made visible to user C. At this point, any of these three users can commit the new item. The Suite communication model allows a user to transmit and receive values (a) on the execution of multiple communication operations and (b) with multiple correctness levels. For instance, user C can receive changes on the execution of not only the TPeriod operation but also the higher-ordered operations TTime and Transmit.



Figure 6: User A Changes the Template This feature allows, for instance, a user of a talk program to receive incremental changes from users connected by fast networks and completed changes from users connected by slow networks. However, Suite’s hierarchical communication model does not allow users to specify arbitrary sets of communication operations and correctness levels. For instance, it does not allow a user to receive changes transmitted by the TPeriod operation without receiving changes transmitted by the TTime operation. As mentioned earlier, we assume that a user willing to send (receive) a value on the execution of a communication operation would also be willing to send (receive) the value on the execution of a communication operation of higher order. Thus, increasing communication operations and correctness levels represent lower collaboration levels. A straightforward generalization of this approach is to allow users to specify arbitrary sets of communication operations and correctness levels (by associating each of these with a separate Boolean attribute, for instance) and intersect these sets to match corresponding transmission and listening attributes. We have currently adopted the more restricted hierarchical approach since it allows a user to think in terms of simple ‘‘collaboration levels’’ that can be increased or decreased (by moving sliders, for instance, as shown in Figure 10) instead of arbitrary sets of communication operations. 3.4.2. Communicating Changes to other Properties Suite uses the following rules for communicating changes to shared attributes and window-properties. Attribute Communication Rule: A change to a shared attribute is communicated immediately to other users. Window Communication Rule: A change to a shared property of a window is communicated to other users as soon as the window system informs the higher-level Suite software about the change. To illustrate the attribute communication rule, consider the ElideString attribute of an interaction variable, which can be changed using the attribute window. Figures 8 and 9 illustrate how a change to this attribute is communicated to other users. User A first specifies the value of the attribute, the name of the attribute, and the path of the variable in which the attribute is to be changed (Figure 8). He then executes the Set command provided by the attribute window, which immediately changes the attribute in both the local copy of the variable displayed to user A and its remote copy displayed to user B (Figure 9). To illustrate the window communication rule, assume that user A moves his window by dragging it to its final destination. The window system informs its client, which is part of the Suite software, about the new position of the



change to the window is communicated to other users such as B. The Suite approach to communicating changes to shared values can also be used for communicating changes to other shared properties. Each coupling set could be associated with the eight transmission and listening attributes, which would determine when changes to the properties in the set are communicated to other users. We have not implemented these attributes for two related reasons: First, we do not believe that giving users the flexibility to control the communication of these properties is important since, unlike values of interaction variables, these properties are not associated with semantics. Second, our decision to use an existing window system in the implementation prevented us from implementing attributes that allowed users to choose, for instance, if positions of windows are transmitted on incremental or completed changes to the positions. 3.5. Specification of Coupling Attributes How should the coupling system resolve the following two seemingly conflicting goals? The set of coupling attributes must support multiuser programs and users with varying coupling needs, but an individual user of a particular multiuser program should specify values of only those parameters that are necessary to tailor that multiuser program to his role. In Suite, values of a large number of coupling attributes must be defined per user and coupling group— some of them such as ScrollCoupled are associated with each window, while others such as ValueCoupled and ViewCoupled are associated with each interaction variable displayed in a window. Clearly, the coupling system would be unusable if each user had to specify values of all of these attributes. Several mechanisms can be used to reduce the user effort required to specify values of coupling attributes. First, a multiuser program can define an initial set of attribute values that are tailored to the function it performs. For

Figure 7: User A’s Partial Result is Displayed to User B but not User C



Figure 8: Changing an Attribute

Figure 9: Immediate Transmission of Attribute Change





instance, a multiuser debugger and program editor may define the True and False values, respectively, for the ScrollCoupled attributes of all windows of all users. A multiuser program can also dynamically change the values of coupling attributes for its users. For instance, a multiuser document editor may dynamically change the values of these attributes as collaboration moves from the ‘‘outline’’ phase to the ‘‘writing’’ phase. Program specification of attributes does not, however, relieve an individual user from tailoring the coupling to his needs. Continuing with the budget example, if the application specifies the False value for the FormatCoupled attribute of each element of the item list, then users such as A and B who wish to couple the formats of their data structures must override the value of this attribute for each of these elements. In this example, the users wished to specify the same attribute definition for a set of values grouped by a Suite value group, the budget.items child group, which includes all descendents (fields and subfields) of the interaction variable budget.items. It would be far more convenient for them if they could give the attribute definition once for all values in the group. Therefore, Suite allows coupling attributes to be defined in arbitrary value groups and inherited by members of a value group. Suite groups values based on their types, contexts, siblings, ancestors, and other properties. While these groupings were defined initially to support easy specification of formatting attributes of interaction variables [12], we have found them appropriate also for specifying values of coupling attributes. Figure 10 shows how the Suite inheritance model can be used to specify the value of coupling attributes once for a whole group of data structures. User A uses his coupling window to set the value of the FormatCoupled and other coupling attributes of the child group budget.items child. The values of this attribute are inherited by all descendents of the list (and their descendents, and so on), as shown by the dashed lines of Figure 11.

Figure 10:Specifying Coupling



The coupling attributes of a value group serve two purposes. First, as described above, they are inherited by all descendents of the value group that do not override them. Second, they determine the coupling of the value group with the corresponding value groups created for the other users. For instance, the FormatCoupled attribute of the value group above determines whether formatting attributes such as Titled are shared with the corresponding value groups created for other users, as shown by the solid lines of Figure 11. Allowing coupling of attributes of arbitrary value groups is crucial since our experience shows that most attribute definitions are made in these groups. Suite further reduces the problem of defining coupling attributes by allowing a user to specify the values of these attributes on behalf of other users. The CommunicationCoupled attribute of a value group determines whether the communication attributes of the value group are themselves shared. The CouplingCoupled sharing attribute of a value group determines whether the other sharing attributes of the value group are coupled. Finally, the WindowCouplingCoupled sharing attribute of a window determines if the other sharing attributes of the window are coupled. Figure 10 illustrates coupling of coupling attributes. Users A and B have set the value of the CouplingCoupled attribute (shown as the highlighted Cplng button ) of the child group of budget.items for the user group others to True, while user C has set it to False. As a result, when user A set the value of the FormatCoupled attribute of the value group for the user group others to True, this value was also changed in user B’s copy of the value group but not in user C’s copy (Figure 10). Unlike the base Suite framework, our coupling model associates windows with customizable attributes. To ease the task of setting attributes of windows, the model supports the additional notion of a window group, which is like a value group except that it groups windows instead of interaction variables. It associates each type of window with a window group that includes instances of the type. For instance, it defines a window group that includes all object windows and another that includes all error windows. In addition, it defines a window group that includes all

budget.items child

budget.items child

FormatCoupled:True

FormatCoupled:True

ElideString:

ElideString:

Titled: True

Titled: True

budget.items[0]

budget.items[1]

budget.items[0]

budget.items[1]

FormatCoupled:True

FormatCoupled:True

FormatCoupled:True

FormatCoupled:True

ElideString:

ElideString:

ElideString:

ElideString:

Titled: True

Titled: True

Titled: True

Titled: True

User 1’s Value Groups

User 2’s Value Groups

Coupled Attribute Values

Inherited Attribute Values

Figure 11: Coupling Value Groups



windows. A window inherits attributes from the most specific group in which it is contained. 3.6. Automation and Extensibility So far, we have looked at coupling from the users’ point of view by focusing on the semantics and specification of coupling. In this section, we look at it from the programmers’ point of view by addressing the implementation of the semantics and specification models described above for a particular multiuser program. We have developed a new system designed to provide automatic and extendible support for these models, which is an extension of the Suite framework [14]. We refer to the new version of our system as Coupled-Suite or simply Suite. The Suite framework allows a program to define interaction variables, value groups, windows, and other interaction entities. Coupled-Suite associates these interaction entities with the coupling attributes defined above, defines default values for these attributes, implements the semantics of these attributes given in the previous sections, provides users with the user-interface described in § 3.5 to change these attributes dynamically, and provides programs with a procedural interface to do the same. As a result, a multiuser program is responsible only for specifying values of coupling attributes— the implementation of their semantics and the user-interface to specify them is the responsibility of the system. Since the system defines default values for coupling attributes, the program may not specify the value of any coupling attribute. Thus, Coupled-Suite supports coupling-transparent multiuser programs, that is, programs that are completely unaware that the interaction entities created by them are coupled with each other. The Suite coupling model includes a rich set of coupling attributes to meet the coupling needs of a variety of multiuser programs. However, not all multiuser programs can specify the couplings they need by simply setting parameters of a predefined coupling model since the coupling desired by a particular program may not have been anticipated in the model or may depend on application semantics. Therefore, Suite allows multiuser programs to extend various aspects of the coupling model. Suite allows programs to execute editor commands such as Transmit on interaction variables. It also supports callbacks that are invoked when various communication operations are invoked. As mentioned earlier, Suite also allows a program to disable sharing of properties among a group of interaction variables by setting the appropriate sharing attributes to False. It also allows a program to update the interaction variables of arbitrary groups of users [14]. A multiuser program can, thus, manually couple properties of interaction variables not automatically coupled by Suite and communicate changes to these properties on the invocation of system-defined communication operations and/or the occurrence of application-defined events. Like Suite, the multiuser program can define its own coupling attributes and allow users to dynamically set their values. To illustrate extensibility, consider how the following two coupling methods not directly supported by the Suite coupling model can be implemented using the Suite primitives for extending the model:

d

Changes to an interaction variable are transmitted only on the execution of the communication operations explicitly specified by the user. The multiuser program can set the TransmitOn attribute of the variable to the highest-ordered operation (Transmit) to disable the Suite hierarchical communication model and define callbacks for the operations



explicitly specified by the user. These callbacks can invoke Transmit to explicitly transmit the changes.

d

A module changed by a team of collaborating programmers is automatically transmitted to code inspectors when all members of the team agree to transmit these changes to the latter. A ‘‘voting tool’’ can record the programmers’ votes regarding transmission of the module. When all programmers have indicated their readiness to transmit the module, the voting tool informs the application managing the module about the event, which asks Suite to invoke Transmit command on one of the versions of the changed module. Clearly, extending the coupling model is more difficult than simply setting values of coupling attributes. We

intend to study the ways in which programmers extend the model and plan to parameterize these methods if possible. 4. Implementation of System Support We have implemented Coupled-Suite by extending the implementation of the Suite framework [14]. The implementation of the framework consists of a dialogue compiler, which builds a symbol table from the type declarations; dialogue managers, each of which manages the interaction entities created for a particular user; a group manager, which manage all groups defined by users and programs; and a set of library routines used by applications to communicate with dialogue managers and group managers. We have implemented the new version of the system by extending the dialogue managers and library routines used to implement the framework. We considered two methods of communicating coupling information among the dialogue managers of an application:

d

Indirect Physical Coupling: A user’s dialogue manager communicates with its peers by sending messages to the application, which distributes them to the peers of the dialogue manager.

d

Direct Physical Coupling: The dialogue manager communicates with its peers by sending them messages directly.3

These two choices are illustrated by Figure 12. We currently support indirect physical coupling for several reasons. In comparison to direct physical coupling, it requires the system to create fewer connections. Indirect physical coupling requires O(n) connections per application while direct physical coupling requires O(n2) connections, where n is the number of users interacting with the application. Our implementation uses reliable connections provided by the operating system, which are scarce resources. A related advantage of indirect physical coupling is that it requires fewer connections to be made/broken when users join/leave the conference, thereby making these operations lightweight operations. Since the indirect approach routes all messages through a central object, it ensures that each dialogue manager receives messages in the same order. In addition, it ensures that a dialogue manager receives the application’s 333333333333333333 3

In both cases, the logical coupling is direct, that is, properties of coupled interaction entities are exchanged among dialogue managers without the intervention of the programmer-defined application routines, which can be coupling-unaware.



Application

Dialog Mgr 1

Application

Dialog Mgr 2

Dialog Mgr 1

Indirect Connection Approach

Collaboration Messages

Dialog Mgr 2

Direct Connection Approach

Feedback+Request Messages

Figure 12: Direct and Indirect Physical Coupling response to a change made by a remote dialogue manager after receiving the change. To illustrate the importance of maintaining this order, consider the events that occur when user A changes the Spent field of a budget item. The application responds to this change by updating the Available field of the item. It is important that user B receives the value for the item from the application after receiving its value from user A, since otherwise the cause would overwrite the response. Under the indirect approach, this order can be achieved trivially whereas under the direct approach, time-stamps or other ordering mechanisms must be used to ensure this order since causes and responses arrive from different processes and along different connections [3]. The primary disadvantage of indirect physical coupling is the cost of sending an extra message to the application. However, our experience with using applications among users connected via a local area network shows that this cost is not noticeable and is negligible in comparison to the screen update cost [7]. Clearly, this may not be true when users are interacting from sites connected via slower networks. Another disadvantage of this approach is that the application can become a central bottleneck. We plan to test our applications across wide-area networks and with large numbers of users and support direct physical coupling if necessary. Communication among dialogue managers ranges from transmission of low-level events such as button presses to high-level events such as changes to variables, depending on the coupling among the interaction entities managed by them. A message containing a new value of an interaction entity must uniquely identify the interaction entity so that the receiving dialogue manager can correctly install the new value. Since the dialogue managers execute in separate address spaces, it is not possible to transmit addresses directly. Single-user Suite supported a naming facility that allowed applications to use logical names to refer to the interaction entities managed by a dialogue manager. This facility is also used by a dialogue manager in multiuser Suite to refer to the interaction entities managed by a



remote dialogue manager. Suite supports logical names also for low-level entities such as buttons managed by the underlying toolkit since it allows them to be coupled. Another issue in the implementation of the model is the mechanism used to implement the Suite rules for matching coupling preferences specified by different users. There are at least two approaches to addressing this issue: First, the transmitting dialogue manager determines when events should be transmitted based on coupling attributes of its local variables and sends all of these events to its peers. Each of the receiving peers decides which of these events are to be accepted based on coupling attributes of its local variables. Second, the transmitting dialogue manager has global knowledge of the coupling attributes of the variables of all of its peers, and transmits only useful information to a peer. The second approach reduces network traffic if changes to coupling attributes occur rarely. However, we have implemented the first approach since it does not require the overhead of maintaining a global coupling database at each site. We have implemented time-based transmission and receipt of information using timers. When a new definition of TransmissionPeriod is made in a value group, the dialogue manager creates a new periodic timer with the specified transmission period. Each time the timer expires, it transmits the appropriate values of interaction variables that inherit the definition of this attribute and starts a new timer. Conversely, when a new definition of ListeningPeriod is made in a value group, the dialogue manager creates a new periodic timer with the specified listening period. Each time this timer expires, it installs new values received for the interaction variables that inherit the attribute definition and starts a new timer. New definitions of TransmissionTime and ListeningTime are handled similarly except that expiration of a timer does not start a new timer. Currently, a dialogue manager starts a timer by executing the UNIX at command, which sends an appropriate message to the dialogue manager when it terminates. Clearly, this approach of executing a new heavyweight process each time a new timer is started is suitable only when timers are started infrequently. We plan to make it more efficient by using a server such as YEAST [20] that responds to messages requesting creation of timers. 5. Example Coupling Policies The coupling mechanisms provided by Suite can be used to define a wide range of coupling policies. Here we show how they can be used to define some example coupling policies. Most of these policies are abstract policies that do not define all aspects of the coupling. Moreover, these policies are not mutually exclusive and some of them are specializations of others. These policies can be used to classify the coupling policies of existing multiuser applications, which are discussed in the next section.

d

Serializable/Cooperative Coupling: Under serializable coupling, the TransmissionCorrectness attribute of each interaction variable is set to the value Committed. As a result, changes to a variable are not made available to others unless they are explicitly committed or ‘‘checked-in’’. This coupling is required to support the traditional, serializable transaction model, which allows sharing of only committed values. 4 Under the converse, cooperative coupling, users are allowed to share a ‘‘partial result’’ [2] or uncommited value of

333333333333333333

4 Serializable coupling is necessary but not sufficient to support the serializable transaction model since concurrency control is also needed to support the latter.


P. Dewan and R. Choudhary each interaction variable.

d

Explicit/Implicit Coupling: Under explicit coupling, the TransmitOn attribute of an interaction variable is set to the value Transmit. As a result, a change made by a user is never transmitted to others unless the former explicitly executes a command to transmit it to the latter. This policy is in the spirit of mail systems— the difference is that a mail system indirectly couples the ‘‘outbox’’ of a user to the ‘‘inbox’’ of another user while this policy directly couples different versions of the same logical data. In either case, transmission does not occur unless a user explicitly executes a ‘‘send’’ or ‘‘transmit’’ command. Under the converse, implicit coupling, a change made to an interaction variable is always transmitted implicitly as a side effect of some communication operation being executed, the correctness level of the value changing, or the time advancing. In both explicit and implicit couplings, listeners are free to determine when they receive the changes.

d

Synchronous/Asynchronous Coupling: Synchronous coupling is a special case of implicit coupling that adds the constraint that the TransmitOn and ListenOn attributes of each interaction variable are set to Increment, and the ListenPeriod or ListenTime attributes are set to ListenNow. As a result, changes made by a user are viewed synchronously by other users. Under the converse, asynchronous coupling, either the transmission or the receipt of the value is delayed for each interaction variable. In either case, there may be a communication delay introduced by the communicating software or the network, though in our experience with local area networks, this delay is not perceptible.

d

Check-In-Check-Out/Automatic Coupling: Check-In-Check-Out is a special form of asynchronous coupling that adds the additional constraint that the ListenTime attribute or the ListenPeriod attribute of each interaction variable is set to the value Infinity. Thus, this coupling requires not only users who make changes to check-in new values but also users viewing changes to check-out these values using the Listen command. This policy is supported by traditional database systems and revision control systems such as RCS [36]. Under the converse, automatic coupling, the values of interaction variable are automatically updated in response to changes to their peers.

d

Semantics/Syntax/Presentation/Access Coupling: Under semantics coupling, the ValueCoupled attribute of each interaction variable is set to

True but not the

FormatCoupled,

ViewCoupled, and

AccessCoupled attributes. As a result, users share only semantic information. Under syntax coupling, the ValueCoupled and FormatCoupled attributes of each interaction variable are set to True but not the ViewCoupled and AccessCoupled attributes. Thus, users see the same syntax for a view of an interaction variable but can see different views of the variable. Under presentation coupling, the first three of these attributes are set to True. Thus, all users viewing a variable see the same presentation. Under access coupling, all of these attributes are set to True.

d

Coarse/Fine Coupling: Under coarse coupling, the value of each coupling attribute is the same in all interaction entities created for a user. Under the converse, fine coupling, the value of a coupling attribute is different in each pair of interaction entities created for each user. Several recent multiuser programs offer a mix of these two policies by supporting both public and private windows.



d

Common/Individualized Coupling: Under common coupling, the value of each coupling attribute is the same in an interaction entity and all of its peers. Under the converse, individualized coupling, the value of each coupling attribute is different in each pair of peer interaction entities.

d

Broadcast/Unicast Coupling: Under broadcast coupling, the group component of each coupling attribute of each interaction entity is set to Others. Under unicast coupling, the group component of a coupling attribute of each interaction entity is set to a group containing a single user.

d

WYSIWIS/No Coupling: WYSIWIS coupling is a special case of synchronous and broadcast coupling with the added constraint that all sharing attributes of all entities are set to True. Under the converse, no coupling, all sharing attributes of all interaction entities are set to False.

d

Suite Default Coupling: The default coupling policy supported by Suite is a special case of cooperative, semantics, explicit, common, coarse, and broadcast couplings. It is important to note that several pairs of these policies represent extreme points in a spectrum of coupling

policies our model can support. For instance, a policy in which the TransmitOn attribute of only some of the interaction variables is set to True is a mix between pure explicit and implicit coupling. Similarly, coupling spectrums

are

defined

by

serializable/cooperative,

synchronous/asynchronous,

check-in-check-out/automatic,

common/individualized, coarse/fine, broadcast/multicast, and WYSIWIS/no couplings. 6. Related Work in Coupling Our work on the Suite coupling model is related to a variety of other works including specific multiuser programs, distributed object-based systems, database systems, shared window systems, and systems for building multiuser interfaces. We describe below some of these works and their relationship with the Suite coupling model. 6.1. Coupling in Specific Tools The Suite coupling model is related to several specific tools for supporting multiuser interaction. (For surveys of some of these tools, see [16] and [25]. ) Like the RTCAL appointment system [31], it supports both completely shared and private windows; like the GROVE outline editor [16] and contemporary talk programs, it supports synchronous coupling; like the PREP coauthoring system [24], it supports asynchronous, check-in-check-out coupling; like CES [17], it supports semantic coupling; like the revised design of Boardnoter, it supports explicit coupling [34]; and like the revised design of Cognoter [34], it supports multicast coupling and allows peer windows to be of different sizes. The Suite coupling model extends the couplings supported by these tools in several related ways. First, these tools define couplings among application-specific entities such as paragraphs and sections while the Suite coupling model defines them among application-independent entities such as interaction variables, value groups, and windows. As a result, it provides an abstract model for describing and comparing the couplings supported by specific tools. Second, it defines several useful couplings not supported by these tools. In particular, it blurs the distinction between (a) completely shared and private windows by defining several intermediate levels of sharing, (b) communication of incremental and transmitted changes by providing several intermediate levels of communication, and (c) sharing of



inconsistent and consistent values by allowing sharing of values checked for intermediate levels of consistency. Third, these tools support fixed couplings, while Suite allows users to interactively and dynamically change the coupling. Finally, these tools do not include an implementation model for easing the task of coupling user-interfaces. 6.2. Coupling in Database/Revision-Control Systems Our coupling model is also related to traditional and recent work in database/revision-control systems. Sharing committed values of Suite interaction variables is similar to sharing values of traditional database entities and file versions. Moreover, sharing uncommitted states of Suite interaction variables is similar to sharing ‘‘partial results’’ of flexible transactions [19]. The Suite coupling model differs from the approach to sharing taken by database systems in five important ways: First, it distinguishes between different types of partial results such as ‘‘incremental raw values’’ and ‘‘validated completed values’’ and allows users to specify the kinds of partial results they wish to share. Second, it provides a flexible communication model that supports automatic display of (partial and committed) results on the screens of users interested in these values. As a result, users are not required to ‘‘poll’’ the system with commands that periodically retrieve values in which they are interested. Third, it supports sharing of not only semantic state but also the state created for interactively manipulating these values such as the formatting attributes of interaction variables and the positions of windows. Finally, it provides a flexible implementation model that allows programmers to extend the coupling model. 6.3. Coupling Arbitrary User-Interfaces Several systems support communication of information among agents managing different user-interfaces. Argus [21], Eden [1], and Clouds [6] allow multiuser applications to be constructed as distributed objects that communicate with each other using high-level remote procedure calls. Field [28] and Mediators [35] provide methods for easily changing the communication patterns among communicating objects, thereby supporting easy-to-change implementation of user-interface coupling. Active databases [23] allow changes made by users to a database to be automatically communicated to other users interested in them. Mercury [18] communicates changes made by a user to an attribute of a syntax tree to users simultaneously editing other syntax trees that depend on that attribute. Suite is similar to these systems in that it supports coupling among agents (dialogue managers) interacting with different users. The main difference between Suite and these systems is that the former addresses communication among dialogue managers of users editing the same data structures while the latter address the more general problem of communication among agents of users changing arbitrary data structures. By restricting the interaction domain, Suite can define a high-level semantic model of coupling and provide users and programmers with high-level parameters to define the coupling. Like Eden and Clouds, Suite also supports distributed objects and provides a high-level remote procedure interface to support interobject communication [8]. This interface has been used in the implementation of multiuser Suite to exchange information among dialogue managers. As shown in [9], it can also be used to exchange information among related application objects communicating with different users. Thus, the approaches used by the Suite



coupling model and communication systems are complementary and address the problem of communicating information among different users at different levels. 6.4. The Rendezvous Coupling Model Flexible coupling is also supported by the Rendezvous [26, 27] architecture for implementing multiuser programs, which was developed independently about the same time as this work. Rendezvous defines a flexible coupling model that supports semantics, syntax, presentation, and access couplings. It also supports an implementation model that supports abstract objects, view objects, shared objects, and constraints. Abstract objects define underlying data while view objects define how these data are viewed and manipulated by users. An abstract object is shared among a group of users by creating a view object for each of these users and defining constraints that keep the abstract object consistent with its view objects. Views of an abstract object are shared by making the associated view objects copies of a special sharing object. The access rights to the views of a sharing object are shared by making guards that authorize actions independent of the identity of the user that invokes the action. There are three main similarities between Rendezvous and Suite: First, like Suite it supports semantics, presentation, and access couplings5. Second, like Suite, Rendezvous supports a fine-grained coupling model that allows different view objects displayed to a user to be coupled differently with their counterparts displayed to other users. Third, the constraint mechanism supported by Rendezvous corresponds to the Suite facilities for interobject communication. Suite extends the Rendezvous semantic model in several ways. In Suite, value, view, format, and access coupling are independent dimensions. It is possible to couple, for instance, the formats of the templates displayed to users A and C without coupling their values (Figure 5). In Rendezvous, sharing of access rights to views of values implies sharing of the views which implies sharing of the abstract objects. Moreover, the Rendezvous semantic model does not directly support coupling of window properties, the user independence principle, coupling of coupling preferences, and multiple communication operations and correctness levels. Furthermore, Rendezvous does not address dynamic changes to coupling and thus does not define a specification model. Finally, the mechanisms supported by Rendezvous and Suite to extend the coupling model are based on different philosophies of programming— Rendezvous supports declarative mechanisms in the form of constraints while Suite offers procedural mechanisms. 7. Applying our Coupling Approach to Other Systems While our approach to coupling was designed specifically for the Suite framework, several aspects of it can also be be applied to other systems. Here we briefly consider traditional interactive systems, window systems/toolkits, and specific applications.

333333333333333333 5

Unlike Suite, Rendezvous does not distinguish between a view of a value and a formatted presentation of it.



7.1. Flexible Coupling in Conventional Interactive Systems Unlike Suite, which supports the editing model of interaction, conventional interactive systems support the traditional teletype interaction model, wherein a user’s display consists of a sequence of input and output lines of text. The teletype model can be used to define several Suite-like coupling parameters. In particular, it can be used to define a ValueCoupled attribute that determines whether echo of the line input by a user is displayed to other users, a TransmitOn attribute that determines the communication operations that trigger transmission of user input, and an AccessCoupling attribute that determines the set of users that can edit a shared line. However, it is not useful or possible to define analogues of all aspects of the Suite coupling model for these systems. It is not useful to define the time-based communication, which is supported in Suite to ensure that users share partial results before commitment of potentially ‘‘long’’ transactions. Under the teletype model, at any time, a user has at most one uncommitted line of input, which he can be expected to commit quickly as part of a ‘‘short’’ transaction. It is not possible to support communication of input on validation or view coupling, since the teletype model does not support the notion of validating user input or creating multiple views of data structures. 7.2. Flexible Coupling in Window Systems and Toolkits Our approach can be applied to varying degrees to extend window systems and toolkits. These systems can associate Suite-like ValueCoupled attributes with the interaction entities managed by them, thereby allowing an application to create both shared and private windows/toolkit widgets. They can also support incremental and timebased communication. Window systems cannot, however, support the notion of sending completed changes or any of the Suite correctness levels, since they treat windows/screens as bitmaps and do not support the notion of completing or committing a sequence of input events. Toolkits can offer these facilities since they are higher-level software supporting the notion of completing and committing entries of validated values. Both window systems and toolkits support multiple views of interaction entities— a window system typically allows the contents of a window to be displayed or iconified, while a composite toolkit widget typically allows displays of different sets of its children. Thus, they can support a Suite-like ViewCoupled attribute to give users the choice of seeing the same or different views of interaction entities. Moreover, both window systems and toolkits can support a Suite-like FormatCoupled attribute, since they distinguish between the state of an interaction entity (e.g. window contents, widget value) and its formatting properties (e.g. window position, widget foreground colour). However, it may not be as useful to apply our coupling approach to these systems since the window system and toolkit concept of the state of an interaction entity may be different from the application concept of a state. Consider the object window of the example application. A window system would consider the displayed state to be the bitmap displayed in the window and a toolkit implementing the window as a text widget would consider the state to be the value of the text buffer displayed in the window, while the application would consider it to be the value of the budget data structure. As a result, it is less useful in these lower-level systems to distinguish between value and format coupling.



7.3. Flexible Coupling in Specific Applications The Suite semantic and specification models of coupling can be used to support flexible coupling in existing collaborative applications. For instance, it can be implemented in (a) the ICICLE code inspector [4] to support both synchronous and asynchronous software inspection in the manner supported by the Suite code inspector [15], (b) the GROVE outline editor [16] to support transmission of changes on completion of a word, a sentence, a paragraph, or a section, and (c) the PREP document editor [24] to allow users to make both private and public annotations. Not all aspects of our approach are applicable to an existing application since the application may offer only a subset of the primitives provided by the Suite generic interaction model. For instance, the ViewCoupled attribute would be useful only in applications that allow users to change views of data structures. 8. Conclusions and Future Work This paper makes several contributions:

d

Coupling Principles: It identifies and motivates principles a coupling model should follow.

d

Coupling Model: It describes a new coupling model that supports these principles.

d

Coupling Policies: It uses the model to describe several example abstract and concrete coupling policies, which can be used to classify coupling policies provided by existing systems.

d

Flexible Coupling in Other Systems: It discusses how aspects of the Suite coupling model can be applied to a variety of interactive systems and shows that it is more applicable to high-level systems such as Suite than low-level systems such as window systems. Our work is only one of the initial steps towards a generic coupling model and we are currently working on

several methods to extend it. We are exploring methods to support multiple, application-defined levels of semantic correctness such as ‘‘compiled’’, ‘‘tested’’, and ‘‘reviewed’’ for a program. We also plan to develop a more flexible coupling model by choosing a more sophisticated interaction model such as one that supports audio [30] and video [22]. We are also exploring the relationship between coupling and concurrency control, undo/redo, and access control. The idea of flexible coupling is related to concurrency control. As the coupling among data structures increases (a) there is sometimes less need for strict concurrency control since users can see each others actions more closely and can thus prevent conflicts (in fact, researchers who have experimented with near-WYSIWIS coupling have reported that few conflicts ever take place [16] ), and (b) it is less likely that strict concurrency control can be supported together with an acceptable response time. We are currently developing and integrating the notions of flexible concurrency control [19, 29] with flexible coupling by identifying the appropriate concurrency control mechanism for a particular coupling level. We are also addressing semantics and implementation of undo/redo in a multi-user application supporting flexible coupling [5]. Finally, we are developing an access control model that allows users to specify only authorized couplings [32]. We plan to use Suite to experiment with various coupling levels. We are currently in the process of refining/building several multi-user programs with varying coupling needs such as an appointment editor, a program editor, a debugger, a testing tool, a talk program, and a project management tool. We are also investigating useful



policies for coupling the user-interfaces of these tools. Finally, we plan to experiment with automatic selection of coupling levels based on minimum performance levels.

Acknowledgments The notions of variable-grained completion units and periodic transmission of values were motivated by a discussion with Clarence Ellis. REFERENCES

[1]

G.T. Almes, A.P Black, E.D. Lazowska, and J.D. Noe, ‘‘The Eden System: A Technical Overview,’’ IEEE Transactions on Software Engineering 11:1 (January 1985), pp. 43-59.

[2]

N.S. Barghouti and G.E. Kaiser, ‘‘Concurrency Control in Advanced Database Applications,’’ ACM Computing Surveys 23:3 (1991), pp. 269-318.

[3]

K. Birman and T. Joseph, ‘‘Exploiting Virtual Synchrony in Distributed Systems,’’ Proceedings of the Eleventh ACM Symposium on Operating Systems Principles, 8-11 November 1987, pp. 123-138. In ACM Operating Systems Review 21:5.

[4]

L. Brothers, V. Sembugamoorthy, and M. Muller, ‘‘ICICLE: Groupware for Code Inspection,’’ Proceedings of the ACM Conference on Computer Supported Cooperative Work, October 1990, pp. 169-181.

[5]

Rajiv Choudhary and Prasun Dewan, ‘‘Multi-User Undo/Redo,’’ Technical Report SERC-TR-125-P, Software Engineering Research Center, Purdue University, August 1992.

[6]

P. Dasgupta, R. C. Chen, S. Menon, M. P. Pearson, R. Ananthanarayanan, U. Ramachandran, M. Ahamad, R. J. LeBlanc, W. F. Appelbe, J. M. Bernabeu-Auban, P. W. Hutto, M. Y. A. Khalidi, and C. J. Wilkenloh, ‘‘The Design and Implementation of the Clouds Distributed Operating System ,’’ Usenix Computing Systems 3:1 (Winter 1990), pp. 11-46.

[7]

Prasun Dewan and Rajiv Choudhary, ‘‘Experience with the Suite Distributed Object Model,’’ Proceedings of IEEE Workshop on Experimental Distributed Systems, October 1990, pp. 57-63.

[8]

Prasun Dewan and Eric Vasilik, ‘‘An Object Model for Conventional Operating Systems,’’ Usenix Computing Systems 3:4 (Dec 1990), pp. 517-549.

[9]

Prasun Dewan, ‘‘A Tour of the Suite User Interface Software,’’ Proceedings of the 3rd ACM SIGGRAPH Symposium on User Interface Software and Technology, October 1990, pp. 57-65.

[10]

Prasun Dewan and Rajiv Choudhary, ‘‘Primitives for Programming Multi-User Interfaces,’’ Proceedings of the 4th ACM SIGGRAPH Symposium on User Interface Software and Technology, November 1991, pp. 6978.

[11]

Prasun Dewan and Rajiv Choudhary, ‘‘Flexible User Interface Coupling in Collaborative Systems,’’ Proceedings of the ACM CHI’91 Conference, April 1991, pp. 41-49.

[12]

Prasun Dewan, ‘‘An Inheritance Model for Supporting Flexible Displays of Data Structures,’’ Software— Practice and Experience 21:7 (July 1991), pp. 719-738 .

[13]

Prasun Dewan, ‘‘Coupling the User Interfaces of a Multi-User Program,’’ ACM SIGGRAPH Video Review, Issue 87, November 1992. Originally part of the Video Program of ACM 1992 Conference on Computer Supported Cooperative Work.



[14]

Prasun Dewan and Rajiv Choudhary, ‘‘A High-Level and Flexible Framework for Implementing Multiuser User Interfaces,’’ ACM Transactions on Information Systems 10:4 (October 1992), pp. 345-380.

[15]

Janet Drake, Vahid Mashayekhi, John Riedl, and Wei-Tek Tsai, ‘‘A Distributed Collaborative Software Inspection Tool: Design, Prototype, and Early Trial,’’ Proceedings of the 30th Aerospace Sciences Conference, January 92.

[16]

Clarence A. Ellis, Simon J. Gibbs, and Gail L. Rein, ‘‘Groupware: Some Issues and Experiences,’’ CACM 34:1 (January 1991), pp. 38-58.

[17]

Irene Greif, Robert Seliger, and William Weihl, ‘‘Atomic Data Abstractions in a Distributed Collaborative Editing System,’’ Conference record of POPL, January 1986.

[18]

Gail E. Kaiser, Simon M. Kaplan, and Josephine Micallef, ‘‘Multiuser, Distributed Language-Based Environments,’’ IEEE Software 4:6 (November 1987), pp. 58-69.

[19]

Gail E. Kaiser, ‘‘A Flexible Transaction Model for Software Engineering,’’ Proceedings of the Sixth International Conference of Data Engineering, February 1990, pp. 560-567.

[20]

Balachander Krishnamurthy and David S. Rosenblum, ‘‘An Event-Action Model of Computer-Supported Cooperative Work: Design and Implementaion,’’ International Workshop on CSCW, Informatik Informationen-Reporte 4, 1991, pp. 132-145.

[21]

B. Liskov and R. Scheifler, ‘‘Guardians and Actions: Linguistic Support for Robust, Distributed Programs,’’ Proceedings of the 9th POPL, 1982, pp. 7-19.

[22]

M. Mantei, R. M. Backer, A. J. Sellen, W. A.S. Buxton, T. Milligan, and B. Wellman, ‘‘Experiences in the Use of a Media Space,’’ Proceedings of CHI’91, April 1991, pp. 203-208.

[23]

M. Morgenstern, ‘‘Active Databases as a Paradigm for Enhanced Computing Environments,’’ Proceedings of the 9th International Conference of Very Large Data Bases , 1983, pp. 34-42.

[24]

Christine M. Neuwirth, David S. Kaufer, Ravinder Chandok, and James H. Morris, ‘‘Issues in the Design of Computer Support for Co-authoring and Commenting,’’ Proceedings of ACM Conference on Computer Supported Cooperative Work, October 1990, pp. 183-195.

[25]

Judith S. Olson, Gary M. Olson, Lisbeth A. Mack, and Pierre Wellner, ‘‘Concurrent Editing: The Group’s Interface,’’ Proceedings of INTERACT ’90, 1990, pp. 835-840.

[26]

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, October 1990, pp. 317-328.

[27]

John F. Patterson, ‘‘Comparing the Programming Demands of Single-User and Multi-User Applications,’’ Proceedings of the 4th ACM SIGRAPH Conference on User Interface Software and Technology, November 1991, pp. 79-86.

[28]

Steven P. Reiss, ‘‘Connecting Tools Using Message Passing in the Field Environment,’’ IEEE Software 7:4 (July 1990), pp. 57-66.

[29]

John Riedl, ‘‘Adaptable Distributed Transaction Systems,’’ Ph.D.Thesis, Department of Computer Science, Purdue University, March 1990.

[30]

J. Riedl, V. Mashayekhi, J. Schnepf, M. Claypool, and D. Frankowski, ‘‘SuiteSound: A System for Distributed Collaborative Multimedia,’’ IEEE Transactions on Knowledge and Data Engineering, Aug 1993.



[31]

Sunil Sarin and Irene Greif, ‘‘Computer-Based Real-Time Conferencing Systems,’’ IEEE Computer 18:10 (October 1985), pp. 33-49.

[32]

Honghai Shen and Prasun Dewan, ‘‘Access Control for Collaborative Environments,’’ Proceedings of the ACM Conference on Computer Supported Cooperative Work, November 1992, pp. 51-58.

[33]

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 (January 1987), pp. 32-47.

[34]

M. Stefik, D. G. Bobrow, G. Foster, S. Lanning, and D. Tatar, ‘‘WYSIWIS Revised: Early Experiences with Multiuser Interfaces,’’ ACM Transactions on Office Information Systems 5:2 (April 1987), pp. 147-167.

[35]

Kevin J. Sullivan and David Notkin, ‘‘Reconciling Environment Integration and Component Independence,’’ Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development Environments, December 1990, pp. 22-33.

[36]

Walter F. Tichy, ‘‘RCS—A System for Version Control,’’ Software—Practice and Experience 17:7 (July 1985), pp. 637-654.

Coupling the User Interfaces of a Multiuser Program - CiteSeerX

Coupling the User Interfaces of a Multiuser Program - CiteSeerX

Suggest Documents

Coupling the User Interfaces of a Multiuser Program - CiteSeerX

Issues in Building Multiuser Interfaces - CiteSeerX

Natural User Interfaces - CiteSeerX

Semantic User Interfaces - CiteSeerX

intuitive user interfaces - CiteSeerX

A Taxonomy of Sequencer User-Interfaces - CiteSeerX

A Framework for Tangible User Interfaces - CiteSeerX

1990-User Modeling and User Interfaces - CiteSeerX

Multiple-Computer User Interfaces: A Cooperative ... - CiteSeerX

The Spatial Metaphor for User Interfaces - CiteSeerX

User Interfaces supporting the Software Process - CiteSeerX

Adaptation and Plasticity of User Interfaces - CiteSeerX

Domain-Specific Design of User Interfaces - CiteSeerX

Rapid Prototyping of Adaptable User Interfaces - CiteSeerX

Interactive Evolution of XUL User Interfaces - CiteSeerX

Design of User Interfaces

Energy-aware User Interfaces: An Evaluation of User ... - CiteSeerX

The influence of design techniques on user interfaces: the ... - CiteSeerX

A Comparative Usability Evaluation of User Interfaces for ... | CiteSeerX

Croquet: A Menagerie of New User Interfaces - CiteSeerX

Intuitive Use of User Interfaces: Defining a Vague Concept - CiteSeerX

2 Usability Evaluation of User Interfaces Generated with a ... - CiteSeerX

Intuitive Use of User Interfaces: Defining a Vague Concept - CiteSeerX

User-Centred Development of Mobile Interfaces to a ... - CiteSeerX