Coupling the User Interfaces of a Multiuser Program

Transcription

1 Coupling the User Interfaces of a Multiuser Program PRASUN DEWAN University of North Carolina at Chapel Hill RAJIV CHOUDHARY Intel Corporation We have evelope a new moel for coupling the user-interfaces of a multiuser program. It is base on an interaction moel an a user-interface framework that allow users an programmers, respectively, to view applications as eitors of ata. It consists of a semantics moel, a specification moel, an an implementation moel for coupling. The semantics moel etermines which properties of interaction entities create for a user are share with corresponing interaction entities create for other users an when changes mae by a user to a property of an interaction entity are communicate to other users sharing it. It ivies the properties of an interaction entity into multiple coupling sets an allows users to share ifferent coupling sets inepenently. It supports several criteria for choosing when a change mae by a user to a share property is communicate to other users incluing how structurally complete the change is, how correct it is, an the time at which it was mae. The specification moel etermines how users specify the esire semantics of coupling. It associates interaction entities with inheritable coupling attributes, allows multiple users to specify values of these attributes, an oes a runtime matching of the coupling attributes specifie by ifferent users to erive the coupling among their user-interfaces. The implementation moel etermines how multiuser programs implement user-customizable coupling. It ivies the task of implementing the coupling between system-provie moules an application programs. The former automatically support a preefine semantic an specification moel which can be extene by the latter. We have implemente the coupling moel as part of a system calle Suite. This paper escribes an motivates the moel using the concrete example of Suite, iscusses how aspects of it can be implemente in other systems, compares it with relate work, iscusses its shortcomings, an suggests irections for future work. Categories an Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distribute Systems istribute applications, istribute atabases; D.2.2 [Software Engineering]: Tools an Techniques user interfaces; D.2.6 [Software Engineering]: Programming Environments interactive; D.3.3 [Programming Languages]: Language Constructs input/output; H.1.2 [Moels an Principles]: User/Machine Systems human factors; H.4.1 [Information Systems Applications]: Office Automation; I.7.2 [Text Processing]: Text Eiting General Terms: Design, Human Factors, Languages Aitional Key Wors an Phrases: collaboration, computer supporte cooperative work, groupware, structure eitors, user interface management systems First Author s aress: Department of Computer Science, University of North Carolina, Chapel Hill, N.C Secon Author s aress: Mail Stop HF3-02 Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, Oregon This research was supporte in part by National Science Founation grants IRI an IRI an in part by a grant from the Software Engineering Research Center at Purue University, a National Science Founation Inustry/University Cooperative Research Center (NSF Grant No. ECD ).

2 P. Dewan an R. Chouhary Coupling User Interfaces 2 1. Introuction A multiuser program creates multiple user-interfaces allowing multiple users, possibly geographically isperse, 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 raise by the necessity to couple the user-interfaces of a multiuser program are: Semantics: In what ways shoul users of a multiuser program be able to couple their user-interfaces? Specification: How shoul users of a multiuser program choose the coupling among their user interfaces? Implementation: How shoul evelopers of a multiuser program implement the esire coupling semantics an specification scheme? In general, a complete set of answers to these questions will epen on application semantics. Nonetheless, it is useful to evelop a coupling moel that ientifies generic answers to these questions. The nature of such a moel is the focus of this paper. It is important to evelop a coupling moel that supports flexibility, ease-of-specification, an ease-ofimplementation. A restrictive coupling moel that requires, for instance, that all users share the complete interaction state will be unusable by users who wish to create both public an private information. On the other han, a flexible coupling moel will be ifficult to use if the moel makes it non-trivial for users to specify the esire coupling. For instance, a coupling moel that supports both public an private state will be ifficult to use if it requires users to name each unit of the public state. Similarly, a multiuser program will be ifficult to implement if the moel offers only low-level support for implementing the esire coupling semantics an specification scheme. Several previous systems (surveye in 6) have aresse the issue of coupling but none of them has been esigne to meet all three requirements. While previous systems offer ifferent couplings, none of them offers multiple couplings. For instance, traitional transaction systems allow users to share only committe changes an require them to explicitly store an retrieve share values, while real-time collaboration tools allow users to share incremental changes an automatically inform users of changes mae by other users. However, no system supports both methos of coupling user interfaces. Moreover, none of the previous systems offers both flexibility an ease of programming. For instance, istribute object systems provie flexible but low-level implementation support that allows programmers to efine arbitrary coupling semantics an specification schemes while share winow systems offer automatic support for a restricte coupling moel that requires all users of a program to share a single interaction state. Finally, previous works have not aresse specification of coupling since since they support fixe, har-wire couplings. We have evelope a new coupling moel esigne to meet all three requirements. The moel is base on an interaction moel an a user-interface framework that allow users an application programmers, respectively, to view programs as eitable ata. It consists of new semantics, specification, an implementation moels for coupling. The

3 P. Dewan an R. Chouhary Coupling User Interfaces 3 semantics moel ivies the properties of an interaction entity 1 into multiple coupling sets an allows users to share ifferent coupling sets inepenently. It supports several criteria for choosing when a change mae by a user to a share property is communicate to other users incluing how structurally complete the change is, how correct it is, an the time at which it was mae. The specification moel associates interaction entities with inheritable coupling attributes, allows multiple users to specify values of these attributes, an oes a runtime matching of the coupling attributes specifie by ifferent users to erive the coupling among their user-interfaces. It inclues a user-interface that allows users to interactively change the coupling. Finally, the implementation moel provies automatic support for the preefine semantics an specification moels an allows application programs to exten these moels. We have implemente the coupling moel as part of a system calle Suite [10]. This paper iscusses the moel using the concrete example of Suite. A previous conference paper [11] briefly iscusses a preliminary version of the coupling moel an a conference vieo publication [13] briefly illustrates the moel. The rest of the paper is organize as follows. Section 2 outlines the interaction moel an user-interface framework use as the bases for the coupling moel. Section 3 is the main part of the paper. It motivates, escribes, an illustrates the various components of the coupling moel. Section 4 aresses the implementation of the moel an Section 5 escribes some example coupling policies supporte by the moel. Section 6 compares the coupling moel with relate work, Section 7 iscusses how it can be supporte in systems other than Suite, an finally, Section 8 gives conclusions an iscusses potential irections for future work. 2. Bases: Interaction Moel an User-Interface Framework As mentione in the previous section, coupling allows the user interfaces create for ifferent users of a program to share state. The nature of the state maintaine by each of these user-interfaces can be efine at various levels of abstraction. For instance, it can be efine as a screen bitmap, a set of winows, or a set of wigets. We refer to a moel escribing the nature of this state as an interaction moel. The esign of semantics an specification moels for coupling epen on the nature of the interaction moel they are base on as we shall see in 7, the higher the abstraction of the interaction moel, the more flexible an high-level these moels can be. Similarly, a user-interface can be implemente using a a variety of user-interface frameworks. For instance, it can be implemente using a winow system or toolkit. The esign of an implementation moel for coupling userinterfaces epens on the framework use to implement the user-interfaces. As we shall also see in 7, the higher the abstractions supporte by the framework, the more automation the implementation moel can offer. We have use the generalize eiting moel an the Suite user-interface framework [14] as the bases for our coupling moel. The generalize eiting moel allows a users to view programs as active ata that can be eite to trigger computations. The interaction entities offere by the moel inclue interaction variables, attributes, value groups, an several winows for inputting commans an isplaying results an error messages. These winows inclue object winows, which isplay interaction variables; menu winows, which are use to input commans; error 1 By an interaction entity we mean a unit of the interaction state create by an interactive program.

4 P. Dewan an R. Chouhary Coupling User Interfaces 4 winows, which isplay error messages, an attribute winows, which are use to specify values of attributes. An interaction variable is a program ata structure isplaye to the user. It can be upate by the program to show results an eite by the user to input new values. Once a user has change a set of interaction variables, he can execute the commit comman to sen the new values of these variables to the program. An attribute is an interaction property of an interaction variable, which can etermine, for instance, the presentation of the variable or the callbacks invoke when the variable is eite by the user. A value group is a group of relate interaction variables that stores attributes share by these variables. Attributes of interaction variables an value groups can be change ynamically both by the program an its users. A multiple-inheritance relation is efine among value groups, which allows a more specific value group to inherit attributes from more general ones. We illustrate the interaction moel using the example of a Suite program, calle example, that allows a user to view an manipulate a buget. The program maintains a list of buget items an allows a user to a new items an change the amount spent for an item. We will use this program as a running example to illustrate the various components of the coupling moel. Figure 1 shows three users, users A, B, an C, interacting with the program. As shown in the Figure, for each user, the program creates an object winow, which isplays a structure interaction variable, calle buget, consisting of several fiels: an item template, a list of committe items, an the total amounts available, allocate, an spent, respectively. The template can be eite to enter a new item in the list an the item list itself can be eite to change the money spent for an item. These ata structures can be manipulate inepenently by the three users, as shown in Figure 1. These interaction variables are groupe into various value groups. For instance, all elements of the item list of the buget are groupe into the value group buget.items chil. A separate version of the value group is create for each user, which groups the buget elements create for that user. Each of the value groups is associate with its own set of attributes, which are inherite by its members. The coupling moel escribe below allows these interaction entities to exchange state, thereby allowing the users to collaborate with each other. Figure 1: Three Users Inepenently Manipulating the Template

5 P. Dewan an R. Chouhary Coupling User Interfaces 5 These interaction entities are manage by the Suite framework, which provies an application an its users with a high-level programming an user interface, respectively, to manipulate interaction entities. Thus application programmers are relieve of the task of implementing the user-interfaces of applications. The semantic an specification components of our coupling moel exten the generalize eiting moel by allowing the interaction entities create for ifferent users of an application to flexibly exchange state. The implementation component of the moel extens the Suite framework by automating the implementation of coupling semantics an specification. In the remainer of the paper, we escribe these components in etail. 3. The Suite Coupling Moel A simple approach to efining a coupling moel is to support a single coupling for all users an programs. However, this approach is too restrictive, for several reasons: Variety of Multiuser Programs: Different multiuser programs may have very ifferent coupling nees. For instance, a multiuser ebugger may wish to isplay the same image of a single share state on all workstations, thereby allowing each user to see the cause-effect relationships, while a multiuser program eitor may wish to allow ifferent users to see ifferent 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 mae, while a mail program may wish to elay the transmission until the user explicitly executes a comman to sen the ata. The notion of flexible coupling is crucial for eveloping a general-purpose system for implementing multiuser programs. Variety of Phases: Sometimes it is useful to couple a share ata structure isplaye by a multiuser program ifferently at ifferent times uring the lifetime of the program. For instance, uring the outline phase of a ocument, users interacting with a multiuser ocument eitor may wish to see a change as soon as it is mae, since they woul be collaborating closely on efining the outline of the ocument; uring the writing phase, they may wish to see a change only after it has been committe, since they woul be working on separate tasks; an finally, uring the integration phase, they may wish to again see a change as soon as it is mae. Minimum Performance Levels: The response time of multiuser programs epens on the kin of coupling among its user-interfaces ecreasing the level of coupling ecreases the number of notification events generate an thus also ecreases the response time of the program. This phenomenon can be use to ynamically tune the coupling of a multiuser program base on the maximum response time acceptable to its users. For instance, parts of the esign of a circuit moule create by a user of a multiuser circuit eitor can be share with other users as soon as they are create or after the esign is complete, epening on the maximum response time acceptable to the users of the eitor. Variety of Roles: Different users interacting with a multiuser application may have ifferent roles an thus may wish their isplays to be couple ifferently. For instance, a programming-language tutor interacting with a multiuser program eitor may wish to see raw values input by beginner stuents; syntactically correct values input by intermeiate stuents, who may not nee help with the syntax of the programming language; an semantically correct values input by avance stuents, who may not nee help with the semantics of the language. Similarly, managers using a

6 P. Dewan an R. Chouhary Coupling User Interfaces 6 multiuser buget eitor to balance a buget may wish to see uncommitte changes to the buget (so that they can agree on a change before they commit it) but may wish their employees to see only committe changes. For these reasons, the Suite coupling moel oes not support a single, fixe coupling. It provies two kins of mechanisms to flexibly couple the interaction entities create for ifferent users of a multiuser program: Parameterize, Peer-to-Peer Coupling: It efines peer relationships among the interaction entities create for ifferent users. Interaction entities that are peers of each other are ifferent versions create by ifferent users of a single logical entity. Thus, in the example above, the Allocate fiels of the buget templates of the users A, B, an C, are consiere peers of each other, an the two winows create for the two users are also consiere peers of each other. Suite automatically couples peers base on values of coupling parameters. These parameters etermine (a) whether a change mae to an interaction entity is to be share with a peer of the interaction entity an (b) if the change is to be share, when it is be reflecte in the latter. Thus, they etermine, for instance, whether a change mae to the value of the Allocate fiel of the buget template of user A is to be share with the corresponing fiel of the buget template of user B, an if is to be share, when the change is to be reflecte in the latter. Suite efines efault values of these parameters an provies application programs an their users high-level mechanisms for ynamically changing these values. Programme Coupling: Suite also supports Suite callbacks, which allow the application program to respon to arbitrary eiting commans, an Suite calls, which allow the program to upate arbitrary interaction entities. The application program can use Suite callbacks an calls to couple interaction entities of ifferent users in arbitrary ways. For instance, it can respon to a change mae to the value of name fiel of a buget item of user A by changing the selection attribute of the Allocate fiel of the buget item of user B, thereby prompting the latter to enter the value for this fiel. Suite calls an callbacks are explaine in etail in [14]. Therefore, in this paper will focus only on the moel provie by Suite to support peer-to-peer coupling. We will refer to this moel as the Suite coupling moel. The Suite coupling parameters efine a coupling space, where each point in the space efines a coupling that can be ynamically selecte by an application or its users. We use an iterative approach to the selection of the coupling parameters. In an initial implementation of the coupling moel, we supporte a small set of coupling parameters since at that time we i not fully unerstan the various aspects of coupling an believe that users woul want to control only a few of them. However, on using the system an better unerstaning the various imensions of coupling, we felt the nee for more flexibility. Therefore, we reesigne the coupling moel base on our experience with the initial implementation an scenarios of interaction with a variety of multiuser programs incluing multiuser talk programs, ebuggers, program emonstrators, circuit eitors, program eitors, an spreasheets. We trie to associate coupling parameters only with those aspects of coupling that users woul want to control. Thus every coupling parameter has been esigne to support either a real scenario we face or a potential scenario we ientifie.

7 P. Dewan an R. Chouhary Coupling User Interfaces Coupling Principles A flexible coupling moel must make several ecisions regaring the semantics, specification, an implementation of coupling. How these ecisions are mae is influence by the coupling principles the moel has been esigne to support. The Suite coupling moel has been esigne to support the following coupling principles: Data Inepenence: The coupling moel shoul allow ifferent interaction entities isplaye to a user to be couple ifferently with their counterparts isplaye to another user. For instance, it shoul allow the coupling between user A s an B s versions of interaction entities I1 to be ifferent from the coupling between their versions of I2, as illustrate by ifferent settings of the coupling ials of Figure 2. Data inepenence allows users to collaborate ifferently on ifferent ata structures. In particular, it allows them to create both private an public ata structures. For instance, it allows a group of users to create a share list of paper references an private comments on these papers. User Inepenence: The moel shoul allow an interaction entity to be couple ifferently with ifferent peers create for ifferent users (Figure 3). User inepenence is require to support a variety of user roles such as the tutor an stuent roles iscusse earlier. I1 I1 I2 I2 User A User B Figure 2: Data Inepenence User A User B I1 I1 I1 User C Figure 3: User Inepenence

8 P. Dewan an R. Chouhary Coupling User Interfaces 8 Flexible Sharing: The moel shoul allow inepenent sharing of semantic, viewing, formatting, access, an selection properties of a pair of interaction entities. This principle is require to support, for instance, the program eitor example of the previous section, which allows users to share semantic properties of programs without sharing their viewing properties. Scenarios to motivate inepenent sharing of other properties are given in 3.3, which efines these properties in the context of Suite. Flexible Communication: It shoul be possible to choose when a change to a property of an interaction entity is communicate to the peers of the entity sharing the property base on whether relate entities have been change, the change property has been valiate to the esire level, an sufficient time has elapse since the change was mae. Flexible communication is require to support multiple phases an minimum performance levels iscusse in the previous section. Other scenarios to motivate this principle are given in 3.4, which escribes the exact set of conitions in Suite that trigger communication of changes to share properties. Iniviual Specification: One approach to the specification of coupling is to require irect specification of the coupling parameters. Each pair of users woul specify the values of the coupling parameters for the pairs of corresponing interaction entities create for them. To illustrate this approach, assume that the parameters P 1, P 2, P 3 etermine the coupling between each pair of interaction entities (Figure 4). Users A an B woul irectly 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 ata- an user- inepenence since it allows inepenent tailoring of the coupling between each pair of peer interaction entities. However, it makes the overhea of collaborating with other users high since users must agree on the values of the coupling parameters of pairs of corresponing interaction entities isplaye to them. Therefore, the coupling moel shoul support an inirect approach to specification of coupling that allows users to inepenently specify how they woul like the interaction entities isplaye to them to be couple with corresponing entities isplaye to other users. The values of the coupling parameters of a pair of corresponing interaction entities isplaye to two users shoul be automatically erive by matching the coupling preferences C1 C2 C3 C1 C2 C3 P1 P2 I1 I1 P3 User A User B Figure 4: Iniviual Specification

9 P. Dewan an R. Chouhary Coupling User Interfaces 9 specifie by these users. Continuing with the example of Figure 4, this approach allows users A an B to inepenently set the values of the coupling preferences C 1, C 2, C 3 regaring their versions of the interaction entity I1, which inirectly etermine the values of the coupling parameters between these versions. 3.2 escribes how these preferences are represente in Suite. Conservative Matching: Iniviual specification allows two users to make ifferent coupling specifications regaring how their interaction entities are to be couple. In such situations, the system shoul take the conservative approach to matching ifferent coupling preferences, that is, it shoul choose the coarser granularity of sharing an communication specifie by the two users, thereby giving users control over which properties of their interaction entities are share with others an when changes to these properties are transmitte to/receive from others. 3.3 an 3.4 escribe an motivate the exact rules use by the moel to match ifferent sharing an communication specifications, respectively. Reuse: The moel shoul allow a specification of a coupling preference to be reuse for ifferent interaction entities of a user, for ifferent peers of an interaction entity, an by ifferent users of a multiuser application. 3.2 an 3.5 escribe how this principle is supporte in Suite. Automation an Extensibility: The system shoul automatically support the coupling semantics an specification moels an allow an application to tailor them. 3.6 iscusses how Suite meets this principle Coupling Attributes In accorance with the principle of iniviual specification, the Suite coupling moel oes not require the irect specification of the parameters of coupling between a pair of interaction entities. Instea, it requires the specification of coupling attributes, which are associate with iniviual interaction entities. Each coupling attribute inicates a user s preference regaring some parameter of the coupling between the interaction entity an the interaction entities create for a group of users. For instance, user A can specify the value (True, suite) for the ValueCouple attribute (efine in 3.3) of an interaction variable to inicate that he woul like the semantic properties of the interaction entity to be share with the corresponing interaction entities create for users in the group suite. The mechanisms provie for efining user groups in Suite are escribe in [14]. These groups can contain arbitrary sets of users incluing specific users an all other users. By allowing specific users in the efinitions of coupling attributes, Suite supports the user-inepenence principle, since an interaction entity can be couple ifferently with each of its peers. By allowing groups of users in the efinitions, it supports the reuse principle, since it allows a coupling specification to be reuse for ifferent peers of an interaction entity. Suite allows a user to make multiple efinitions of a coupling attribute with ifferent values for the group fiel. For instance, it allows user A to make the aitional efinition, (False, others), for the ValueCouple attribute of the interaction variable. In case of conflicts, Suite chooses the value associate with the most specific group. Thus, in this example, it chooses the first efinition of of ValueCouple for a member of the group suite, since suite is a more specific group than others.

10 P. Dewan an R. Chouhary Coupling User Interfaces 10 The exact set of coupling attributes are given below. In the remaining iscussion, we will omit the group fiel of the value of a coupling attribute of an interaction entity when iscussing the coupling of the entity with a specific peer. Thus, when iscussing the coupling between two interaction variables create for users A an B, respectively, if we say that the ValueCouple attribute of the former variable is False, we strictly mean that among all efinitions of the ValueCouple attribute whose secon fiels name groups containing B, False is the value associate with the most specific of these groups Sharing of Properties Suite ivies the properties of each interaction entity isplaye to a user into several isjoint coupling sets an associates a coupling set with a boolean sharing attribute, which etermines if the properties in the set are share with the corresponing interaction entities isplaye to other users. Like values of other coupling attributes, values of sharing attributes are consiere by the system to be hints given by users regaring sharing of properties of the interaction entities isplaye to them. Suite uses the following rule to etermine which properties of a pair of corresponing interaction entities are share: Sharing Rule: The properties in a coupling set are share between a pair of corresponing interaction entities iff the associate 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 corresponing entities if the associate 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 share with others. The converse approach woul allow a user to share/upate the interaction state of another user against the wishes of the latter. This approach can be simulate in Suite if users have explicitly set the value of the CouplingCouple attribute, iscusse in 3.5. We escribe below the sharing attributes an coupling sets currently supporte in Suite. The ValueCouple sharing attribute of an interaction variable etermines whether the value of the variable is share with corresponing interaction variables. To illustrate its role, consier the example template. Shoul changes mae to the template by user A be seen by other users such as B an C? The answer epens on the level of collaboration between the users. If two users are working together to a a new item, then changes mae to the template by one of them shoul be communicate to the other. On the other han, if they are inepenently aing items, then they shoul not share changes to the ata structure. The ValueCouple attribute allows them to ecie whether the values of the two templates are share or private. Since this attribute is associate with each interaction variable, users A an C can share changes to the list of items but not the item template, as illustrate by Figure 5, which shows the winows of users A, B, an C. The coupling set associate with the ValueCouple attribute contains not only the value of the variable but also the Uninitialize an Erroneous attributes of the interaction variable. The Uninitialize attribute etermines whether the variable has been initialize if the variable is uninitialize then Suite isplays a placeholer for it, as illustrate by the winow of user C (Figure 5), which contains an uninitialize value for the Allocate fiel of the template. The Erroneous attribute etermines whether the value of the variable is

11 P. Dewan an R. Chouhary Coupling User Interfaces 11 Figure 5: Dimensions of Sharing. The templates of A an C are ifferent since they are not value couple. Items that are elie in A s isplay are also elie in B s isplay since they are view couple. The elie views of the rent items in A s an C s isplay are presente ifferently since they are not format couple. The winows of A an C show the same ata on the first line since they are scroll couple. The Available fiels of all three users are selecte since they are selection couple. The coupling winows in Figure 10 show how some of these couplings were specifie. erroneous if the value is erroneous an error message is isplaye in the error winow, as illustrate by the error winows of the users A an B (Figure 5), which escribe the error in the share Allocate fiel of the template. We inclue these attributes of an interaction variable in the ValueCouple coupling set since they are closely relate to the value of the variable together with the value of a variable they efine its semantic state. It is possible to create multiple views of a variable showing ifferent parts of it. In Suite, the view attributes of a variable etermine which parts of the variable are isplaye. Currently, Suite supports only one view attribute, Elie, which etermines if the components of the value are isplaye or hien. In the future, we plan to support aitional view attributes that select the components of a value that are isplaye. The ViewCouple attribute of an interaction variable etermines whether its view attributes are share with corresponing interaction variables. Figure 5 illustrates view coupling in Suite. The views of the elements of the item list isplaye to user A are couple with the corresponing views isplaye to user B but not user C. As a result, when A execute the Elie comman to elie the first two elements of the item list, the elements were elie in both winows. View coupling allows users to refer to ata structures in terms of their views in aition to their values. For instance, users A an B can refer to the thir item of the item list as the unelie item. A view of an interaction variable may be formatte in ifferent ways. For instance, the elie presentation of the first item of the item list can be <Elie> or <Rent...>. Suite associates an interaction variable with a set of format attributes, which etermine how its views are formatte. An example of a format attribute is the ElieString attribute, which etermines the elie presentation of the variable. The FormatCouple attribute of an interaction variable etermines whether the formatting properties of the variable are share with corresponing interaction variables. Figure 5 illustrates format coupling in Suite. User A shares the formatting properties such as ElieString of the elements of the item list with user B but not with user C. Format coupling allows users to efine formats for others. In aition, it allows them to refer to ata structures in terms of their presentations in

12 P. Dewan an R. Chouhary Coupling User Interfaces 12 aition to their views an values. For instance, it allows users (interacting from colour screens) to refer to the re item. Access attributes of an interaction variable etermine the set of commans a user can execute on a variable an inclue the Selectable, ReaOnly, an other attributes escribe in [32]. The AccessCouple attribute of an interaction variable etermines whether the access attributes of the variable are share with corresponing interaction variables. The SelectionCouple attribute of an interaction variable etermines whether the selecte property of the variable is share with corresponing interaction variables. Selection coupling can be use, for instance, by user A to raw the attention of user B an C to the Total Available fiel (Figure 5). Suite also allows coupling of properties of corresponing winows create for ifferent users. Each winow isplaye to a user is associate with the ScrollCouple sharing attribute, which etermines whether the scrollbar of the winow is couple with scrollbars of the peers of the winow. Scroll coupling, as reporte in [33], can lea to scroll wars when users want to inepenently browse through a ocument. However, it is useful, for instance, when a user is emonstrating the user interface of an application to other users or a group of users are together browsing through some ocument. In Suite, when two winows are scroll couple, the first lines of these winows isplay the first lines of presentations of interaction variables that are peers of each other, as shown in Figure 5, where the object winows of users A an C are scroll couple. Thus, we support linking of ata or semantics uring couple scrolling rather than linking of syntax. 2 Linking of syntax is not always possible in Suite since two winows that are scroll couple, such as the winows of users A an C, may show ifferent presentations of interaction variables. Thus, it is possible for views an formats of variables isplaye in a winow to be couple without the scrollbars of these winows being couple, an vice versa, thereby allowing, for instance, (i) A an B to see the same presentations of interaction variables (such as the item list) but ifferent parts of these presentations an (ii) A an C to see the same interaction variables but ifferent views an presentations of these variables. Suite also associates each winow with an ActionCouple attribute, which etermines whether actions performe in that winow for invoking commans are couple. For instance, if the ActionCouple attributes of the menu winows of A an B are set to True, then if A clicks on the Elie button in his menu winow, the button is highlighte in the menu winows of both A an B an the Elie comman in execute for both users. We allow these couplings to be controlle separately since users may want scroll coupling without action coupling. For instance, users browsing through a ocument together may want scroll coupling but not action coupling. So far, we o not know of a scenario in which users may want action coupling without scroll coupling. To support group emonstrations, Suite allows coupling of several other properties of share winows incluing their position an size. 2 If the coupling policy supporte is syntax coupling (see 5), then there is no ifference between linking of semantics an syntax uring share scrolling.

13 P. Dewan an R. Chouhary Coupling User Interfaces Communicating Changes to Share Properties When shoul a change to a share property mae by a user be communicate to other users? Let us first consier the value of an interaction variable Communicating Changes to Values By efault Suite communicates changes to values of interaction variables to other users when they are committe. Sometimes, however, a user may wish to consult other users about a change value before committing it. Therefore, like talk programs an share winow systems, Suite also supports communication of every change to a share value as soon as it is mae, thereby supporting sharing of uncommitte values or partial results [19]. These two approaches represent two extreme methos for communicating changes to share properties. Often users want mile grouns between communicating changes when they are committe an communicating them as they are mae. Therefore, Suite also allows users to choose several intermeiate methos of communicating changes. It allows users to specify ifferent criteria for transmitting changes mae by them an receiving those mae by others, thereby allowing, for instance, shy users to receive incremental changes mae by others but transmit only committe changes mae by them an busy users to transmit incremental changes mae by them but receive only committe changes mae by others. It supports the following criteria for selecting the communication metho: User Operations: It efines a set of user operations on interaction variables that can trigger communication of changes to the values of these variables to other users an allows both the transmitting an receiving users to choose which of these operations trigger communication of these changes. These operations inclue Increment, which is execute by a user to make an incremental change to the ata structure, Complete, which is execute by a user to inicate completion of a series of incremental changes to the ata structure, an Transmit, which is execute by a user to explicitly eman transmission of changes to the ata structure. These three operations are abstract operations an must be mappe to concrete commans provie by the eitor use to moify the presentation of the ata structure. Suite currently provies two eitors, a text-eitor for eiting textual presentations of ata structures an a bar eitor for eiting presentations of ata structures represente as bars. In the case of the text eitor, insertion or eletion of a character in the presentation of a ata structure is consiere invocation of the Increment operation, an movement of the insertion point away from the presentation of the change ata structure is consiere execution of the Complete abstract operation. In the case of the bar eitor, ragging the bar is consiere execution of the Increment operation an releasing the bar is consiere execution of the Complete operation. In either case, clicking on the Transmit menu button is consiere execution of the Transmit operation. A user may wish to complete a series of changes to the fiels of a structure interaction variable before communicating these changes to others. For instance, user A may wish to communicate a series of changes to the fiels of the item template when he moves the cursor away from the complete template an not as he moves it away from each change fiel. Suite provies 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

14 P. Dewan an R. Chouhary Coupling User Interfaces 14 CompletionUnit attribute is True. Thus user A can achieve the coupling above by setting the CompletionUnit attribute of the template to True an each of the fiels of the template to False. Time-base Communication: Suite also allows users to request perioic communication of changes with perios specifie by them, thereby allowing, for instance, users collaborating on a software esign to automatically exchange changes at the en of each ay. Similarly, it allows users to request communication of changes at a particular time, thereby allowing, for instance, coe inspectors to automatically receive changes mae by programmers at the times inspection meetings take place. It allows the value of a variable to be transmitte to other users at the start of each of its transmission perios or at its transmission time. Similarly, it allows new values receive for an interaction variable to be isplaye at each of its listening perios or at its listening time. Suite invokes the TPerio ( LPerio ) system operation on the variable at the start of each of its transmission (listening) perios an the TTime ( LTime ) system operation on the variable when the current time becomes equal to its transmission (listen) time. Correctness of Communicate Changes: Suite allows (transmitting an receiving) users to specify the correctness of values exchange among them, thereby supporting, for instance, the tutor-stuent example presente earlier. The communication correctness levels inclue Raw, Parse, Valiate, an Committe, which are associate with values that have been change, checke for syntax errors, checke for semantic errors, an committe, respectively. In Suite, a committe value is guarantee to be free of semantic errors an a value free of semantic errors is guarantee to be free of syntax errors [9]. Suite efines two attributes, calle feeback attributes, which etermine when a value is checke for syntactic correctness, semantic correctness, an committe [9]. We escribe below communication attributes an communication rules that allow the coupling moel to support all of the communication criteria escribe above. Transmitting Changes Consier first the criteria use by users to etermine when changes mae by them are transmitte to other users. One metho for accommoating all of these criteria is to efine for each of them a Boolean attribute that etermines whether the criterion is to be use for transmitting changes to the interaction variable. For instance, it is possible to associate an interaction variable with the TransmitOnIncrement an TransmitOnPerio attributes etermining whether values of the variable shoul be transmitte on the Increment an TPerio operations on the variable; an the TransmitOnParsing an TransmitOnValiation attributes etermining whether parse an valiate values of the variable shoul be transmitte. This approach is general since it allows a user to select each criterion inepenently. On the other han, it also requires a large number of coupling attributes. We have simplifie the approach using two observations an assumptions. The observations are: (1) A value of a variable that is guarantee to have a certain correctness level is also guarantee to have lower correctness levels. For instance, a valiate value of a variable is guarantee to be parse. As a result, it is not necessary to efine a separate Boolean attribute for each of the correctness levels it is sufficient to efine a single attribute that inicates the minimum correctness a transmitte value shoul have.

15 P. Dewan an R. Chouhary Coupling User Interfaces 15 (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 efine separate attributes for sening incremental changes an complete changes to a variable since sening the former implies sening the latter. The assumptions are: (1) A Complete operation is execute on a change value before a TPerio operation is execute on it, an the latter is execute on the value before the TTime operation is execute on it. We make this assumption because we expect the Complete operation to be execute on a change value within a few minutes, the TPerio operation within a few hours, an the TTime operation within a few ays. This assumption implies that it is not necessary to sen perioic (time) changes if complete (perioic) 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 execute by them to request transmission of changes. Thus it is not necessary to associate this operation with a transmission attribute. We can now efine our scheme for transmitting values. Users specify their preferences regaring transmission of values of change interaction variables by efining values of the transmission attributes of these variables. Suite associates each interaction variable with four transmission attributes, TransmissionPerio, TransmissionTime, TransmitOn, an Transmission- Correctness. The TransmissionPerio an TransmissionTime attributes specify the transmission perio an time, respectively, of the interaction variable. The TransmitOn an TransmissionCorrectness attributes specify which communication operations execute on an active variable trigger transmission of change values an how correct these values must be before they are transmitte. Communication operations inclue the Increment, Complete, an Transmit user operations, an the TPerio an TTime system operations. Suite efines the following orers on the communication operations an correctness levels. Increment < Complete < TPerio < TTime < Transmit Raw < Parse < Valiate < Committe It uses these orers in the following transmission rule: Transmission Rule: The value of a change variable is always transmitte when it is committe. In aition, the value is transmitte 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 escribe above. Receiving an Installing Changes Our approach to receiving values from other users is a ual of our approach to transmitting values. Users specify their preferences regaring receiving values of change variables by efining values of the listening attributes, ListenOn an ListeningCorrectness, which take the same values as their transmission counterparts. Suite

16 P. Dewan an R. Chouhary Coupling User Interfaces 16 uses the following rule for etermining which values of change variables are receive: Receiving Rule: The value of a change variable is always receive when it is committe. In aition it is also receive if its transmission was cause by the execution of a communication operation equal to or greater than the value of the ListenOn attribute of the (receiving) variable an the correctness of the variable is greater than or equal to the value of the ListeningCorrectness attribute of the variable. The transmission an receiving rules allow both the transmitter an receiver to etermine which communication operations trigger communication of change values an how correct these values must be before they are communicate. However, they o not allow the receivers to influence the times at which changes mae by other users are mae visible to them. For instance, they o not allow receivers to request that they view other users changes at the en of each ay. To overcome this limitation, Suite oes not immeiately isplay a new value receive for an interaction variable to the user listening for it. Instea, it stores the value in a receive buffer associate with the variable, which always hols the latest value receive for the variable. The value of the receive buffer is assigne to the interaction variable when it is installe by the system. Separating the notions of receiving an installing values allows listening users to influence the times at which receive values are isplaye to them. They specify their preferences regaring the times at which receive values shoul be installe by efining values of the listening attributes, Listening- Perio an ListeningTime. Suite uses the following rule for installing receive values: Installation Rule: The installation of a value receive for an interaction variable epens on the Listening- Perio an ListeningTime attributes of the variable. The value is installe at the earlier of the listen time an the start of the next listening perio of the variable. The value is installe immeiately if either of these attributes has the value ListenNow. Users can explicitly install receive values by executing the Listen comman. To illustrate our communication moel, consier the fiels of the item template. Assume that user A has set the TransmitOn an TransmissionCorrectness attributes of these fiels to Increment an Raw, respectively. Assume also that user B has set the values of the ListenOn an ListeningCorrectness attributes of these fiels to Transmit an Raw, respectively, an user C has set their values to LPerio an Valiate, respectively. Finally, assume that user B has set the values of the ListeningPerio attributes of these fiels to ListenNow an 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 receive immeiately by user B or C. Figure 7 shows what happens when user A executes the Transmit comman to transmit the template. This partial result is isplaye to B but not C, who is receiving only valiate values an not installing them immeiately. Notice that the item list has not yet been upate by the unerlying application since the new template has not been committe. Either user A or B can now correct the mistake. Within an hour after the value is correcte it will be mae visible to user C. At this point, any of these three users can commit the new item. The Suite communication moel allows a user to transmit an receive values (a) on the execution of multiple communication operations an (b) with multiple correctness levels. For instance, user C can receive changes on the execution of not only the TPerio operation but also the higher-orere operations TTime an Transmit.

17 P. Dewan an R. Chouhary Coupling User Interfaces 17 Figure 6: User A Changes the Template This feature allows, for instance, a user of a talk program to receive incremental changes from users connecte by fast networks an complete changes from users connecte by slow networks. However, Suite s hierarchical communication moel oes not allow users to specify arbitrary sets of communication operations an correctness levels. For instance, it oes not allow a user to receive changes transmitte by the TPerio operation without receiving changes transmitte by the TTime operation. As mentione earlier, we assume that a user willing to sen (receive) a value on the execution of a communication operation woul also be willing to sen (receive) the value on the execution of a communication operation of higher orer. Thus, increasing communication operations an correctness levels represent lower collaboration levels. A straightforwar generalization of this approach is to allow users to specify arbitrary sets of communication operations an correctness levels (by associating each of these with a separate Boolean attribute, for instance) an intersect these sets to match corresponing transmission an listening attributes. We have currently aopte the more restricte hierarchical approach since it allows a user to think in terms of simple collaboration levels that can be increase or ecrease (by moving sliers, for instance, as shown in Figure 10) instea of arbitrary sets of communication operations Communicating Changes to other Properties Suite uses the following rules for communicating changes to share attributes an winow-properties. Attribute Communication Rule: A change to a share attribute is communicate immeiately to other users. Winow Communication Rule: A change to a share property of a winow is communicate to other users as soon as the winow system informs the higher-level Suite software about the change. To illustrate the attribute communication rule, consier the ElieString attribute of an interaction variable, which can be change using the attribute winow. Figures 8 an 9 illustrate how a change to this attribute is communicate to other users. User A first specifies the value of the attribute, the name of the attribute, an the path of the variable in which the attribute is to be change (Figure 8). He then executes the Set comman provie by the attribute winow, which immeiately changes the attribute in both the local copy of the variable isplaye to user A an its remote copy isplaye to user B (Figure 9). To illustrate the winow communication rule, assume that user A moves his winow by ragging it to its final estination. The winow system informs its client, which is part of the Suite software, about the new position of the

18 P. Dewan an R. Chouhary Coupling User Interfaces 18 change to the winow is communicate to other users such as B. The Suite approach to communicating changes to share values can also be use for communicating changes to other share properties. Each coupling set coul be associate with the eight transmission an listening attributes, which woul etermine when changes to the properties in the set are communicate to other users. We have not implemente these attributes for two relate reasons: First, we o 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 associate with semantics. Secon, our ecision to use an existing winow system in the implementation prevente us from implementing attributes that allowe users to choose, for instance, if positions of winows are transmitte on incremental or complete changes to the positions Specification of Coupling Attributes How shoul the coupling system resolve the following two seemingly conflicting goals? The set of coupling attributes must support multiuser programs an users with varying coupling nees, but an iniviual user of a particular multiuser program shoul 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 efine per user an coupling group some of them such as ScrollCouple are associate with each winow, while others such as ValueCouple an ViewCouple are associate with each interaction variable isplaye in a winow. Clearly, the coupling system woul be unusable if each user ha to specify values of all of these attributes. Several mechanisms can be use to reuce the user effort require to specify values of coupling attributes. First, a multiuser program can efine an initial set of attribute values that are tailore to the function it performs. For Figure 7: User A s Partial Result is Displaye to User B but not User C

19 P. Dewan an R. Chouhary Coupling User Interfaces 19 Figure 8: Changing an Attribute Figure 9: Immeiate Transmission of Attribute Change