Principles of Designing Multi-User User Interface ... - Semantic Scholar

Download PDF
14 downloads 152594 Views 74KB Size Report
Comment
core and (b) a dynamic number of users per multi-user application. In the single-user case, .... The creator of the semantic object decides where it executes and ...
Principles of Designing Multi-User User Interface Development Environments Prasun Dewan Department of Computer Science, Purdue University, W. Lafayette, IN 47907, U.S.A.

Abstract Domain-independent, high-level, flexible, and efficient user interface development environments (UIDEs) are required for easing the task of developing multi-user interfaces. This paper describes several principles of designing such environments, gives motivation for supporting them, and identifies existing systems that follow them. Some of these principles are also well-accepted principles of designing single-user UIDEs—multi-user interaction provides new reasons for accepting them. Others are single-user principles that have been adapted for the multi-user case, while still others are new principles that have no counterparts in the single-user case. These principles address the functionality and architecture of a multi-user UIDE and the programs supported by it.

Keyword Codes: C.2.4; D.2.2; H.1.2 Keywords: Distributed Systems; Tools and Techniques; User/Machine Systems 1. INTRODUCTION Most of the current principles of designing user interface development environments (UIDEs) [5, 15, 24, 28] have been derived assuming that a single user interacts with an application at a time. In this paper, we consider principles of designing multi-user UIDEs. Since the field of multi-user interaction is in its infancy, it is not currently possible to identify all of these principles, identify all of the consequences of supporting them, or with absolute confidence separate fundamental principles from promising approaches. This paper is only a first-cut effort at identifying important principles in this area. Moreover, while it motivates its selection of the principles, this selection is meant to be controversial, which is consistent with the theme of a working conference such as this one. Our discussion is based on our research in developing a multi-user UIDE called multi-user Suite [7, 8]. The principles we describe here address the functionality and architecture of a multi-user UIDE and the programs supported by it. These principles have been derived assuming that four fundamental goals of a UIDE are:

d

domain-independence, that is, supporting general applications and not a particular application domain such as conferencing tools;

d

automation, that is, providing high-level support for building interactive programs that automatically handles low-level details of interacting with users;

d

flexibility, that is, allowing its users (programmers and end-users) to easily tailor the multi-user programs to their needs; and

d

iterative design, that is, allowing its users to incrementally develop the user interface of a multi-user program.

This set of goals is not an exhaustive set of goals of an ideal UIDE since it does not include, for instance, support for help [26]. These are the goals that form a basis for our first-cut choice of the principles of designing multi-user UIDEs. Several of these principle address the architecture and functionality of a multi-user program— subjects that are of concern not only to the designers of multi-user UIDEs but also designers of multi-user programs. All of these principles that do not explicitly contain the term UIDE fall in this category and are thus guidelines that can be used by both kinds of designers. 2. PRINCIPLES The principles are given in italics. Some of them are also well-accepted principles of designing single-user UIDEs—multi-user interaction provides new reasons for accepting them. Others are single-user principles that have been adapted for the multi-user case, while still others are new principles that have no counterparts in the single-user case. Logical Separation Perhaps the most widely accepted of all the single-user principles is the principle of logical separation of concerns: Functional cores and user interfaces of interactive programs should be separated into different modules. Logical separation makes it possible to easily create multiple user interfaces to a single functional core. In particular, in both the single-user and multi-user case, logical separation makes it easy to experiment with different user interfaces to a functional core. In the multi-user case, logical separation also supports WYSINWIS (What You See Is Not What I See) interaction [18], that is, multi-user interaction that allows multiple users to interact through different user interfaces. To illustrate the importance of supporting such interaction, consider an example multi-user Suite program that allows multiple users to view and manipulate the grades of the students of a class. Figure 1 illustrates multi-user interaction with the application involving two users, users pd and rxc. WYSINWIS interaction with the application allows, for instance, the two users to create private comments in their comments windows and see different presentations of the cutoff scores. Logical separation makes it easy to create multiple user interfaces such as these that access a common functional core. For this reason, multi-user Suite [8], Rendezvous [22, 23], GROVE [9], and CES [13] support this principle. Logical separation is also necessary to support the principles of concurrent command processing and physical separation, which are described below.

Figure 1: An Example Multi-User Application Multiple, Dynamic Linkage It should be possible to link a functional core with multiple user interfaces simultaneously and to create/destroy a user interface dynamically. This principle is a variation of the dynamic, multiple linkage rule given in in the PAC model [4] for functional abstractions and their presentations. In the single-user (and multiuser) case, multiple, dynamic linkage allows, for instance, a single-user to simultaneously create both a textual and graphical user interface to a functional core and to dynamically add/delete these user interfaces. In the multi-user case, it is necessary to support (a) WYSINWIS interaction, which requires multiple simultaneous user interfaces per functional core and (b) a dynamic number of users per multi-user application. In the single-user case, it may be possible to place a static bound on the maximum number of user interfaces that will be simultaneously linked to a functional core. Typically, each of these interfaces displays different presentations of the functional core data structure and the maximum number of such presentations may be bound at application-definition time. However, in the multi-user case, it is not usually possible to statically determine the maximum number of users that will wish to simultaneously connect to an application at any one time. Therefore, a multi-user system must be more flexible than a single-user system in the kind of linkage mechanism it supports.

Mixed Control The UIDE must provide both internal and external control. An important issue in the design of single-user UIDEs is the kind of dialogue control it offers [24], which determines the interaction objects displayed to a user and and the sequence in which these interaction objects are manipulated by him. Internal control puts the control with the application while external control places the control with the user. Traditional teletype-based systems offer internal control, thereby allowing the application to ensure that preconditions for the modification of an interaction object are met before the object is allowed to be modified. However, they severely reduce the flexibility of user interaction since they create ‘‘modes’’.1 Therefore, the trend in modern single-user UIDEs is to support the modeless external control. In the single-user case, it is often possible to recommend pure external control since few single-user applications require modes. However, in the multi-user case, it is important to support internal control to prevent conflicting interaction. Moreover, as in the single-user case, it is important to also support external control to give users the flexibility of choosing which of the non-conflicting sequences of actions they perform. Continuing with the example of Figure 1, internal control would prevent, for instance, users rxc and pd from simultaneously changing one of the cutoffs while external control would allow, for instance, user pd to change, in any order, all of the cutoffs not being modified by rxc. A surprising corollary of this principle is: Modes is a necessary feature in multi-user interfaces. The likelihood that these concurrency-control modes will be confusing to the users can be reduced by making each user aware of the actions of other users, as discussed later. Multi-Thread Dialogues User-interfaces must offer multi-thread dialogues. Multi-thread dialogues [12] create more than one thread of interaction per application. In the single-user case, they give the user external control by giving him the flexibility of choosing when each thread is ‘‘scheduled’’, that is, which dialogue thread receives the next user input. In the multi-user case, multi-thread dialogues also allow the workload to be broken into individual pieces that can be carried out concurrently by different users. Therefore, all multi-user systems known to us support multi-thread dialogues. This principle does not address how logical threads in a dialogue are mapped to physical threads or processes that are independently (and possibly concurrently) scheduled by the underlying system. The next section addresses this issue. Concurrent Command Processing The Chiron abstract model [28] for single-user UIDEs suggests that the functional and interface code must execute as coequal processes exchanging messages. We extend this principle for the multi-user case: 333333333333333333333333333333333333

Internal control creates ‘‘modes’’ since the response of the system depends on the state of the interaction.

1

Each user’s interaction with the application must be managed by a separate process, which must be distinct from the process that executes the functional core of the application. Implementation of a multi-user, multi-thread dialogue using a single process would allow a user of the application to get starved and hide the concurrency within the dialogue from a multiprocessor. This principle allows the top-level dialogues threads to be mapped to independently and possibly concurrently scheduled processes. Continuing with the example, this principle advocates that a functional process be created for managing the student grades and two user interface processes be created for users rxc and pd for managing the interactions between these users and the functional process. This principle gives only the minimum number of processes that must be created for a multi-user application. Naturally, it may be desirable to create multiple processes per user and functional core if the cost of creating and communicating among these processes is not high, which depends on the application and the underlying system. Both Rendezvous and multi-user Suite support this principle. For each multi-user program, Rendezvous creates an ‘‘abstract process’’, which stores the abstractions defined by the program; and for each user of the program, it creates a ‘‘view’’ process, which stores the interaction objects created for manipulating these abstractions. Similarly, for each multi-user program, multi-user Suite creates a central ‘‘semantic object’’; and for each user of the program it creates a ‘‘dialogue manager’’, which manages the user’s interaction with the semantic object. Physical Separation A multi-user UIDE must allow the functional component and each user interface component to execute in a separate address space and host. Executing each of these components in a separate address space provides tolerance for failure since a crash of one of them does not crash the whole application. Moreover, in most operating systems such as UNIX, an address space can be associated with its own set of access rights and environment variables. In these systems, it also allows different users to have different sets of access rights and environment variables. Executing each of these components on a separate host can increase the efficiency of the application since it allows the user interface component of each user to execute on his workstation, thereby providing local response, which is typically faster than remote response [16]. Continuing with the example, physical separation allows, for instance, the dialogue manager (user interface component) of user pd to (a) crash without crashing the dialogue manager of user rxc or the semantic object (functional component), (b) have different access rights than the dialogue manager of user rxc, and (c) be placed on the workstation of user pd, thereby providing local response. It is important to note that this principle only requires that the UIDE give the application-programmer/end-user the option of physically separating the components of the application—it does not require that these components be always physically separated. Physical separation does increase the overhead of communicating among the components and for each application this cost must be weighed against the benefits offered by physical separation. Our experience shows that this cost is often negligible in current environments [6]. Therefore, we believe that a UIDE must give the application programmer/end-user the option of physical separation.

The benefits of physical separation can also be obtained by replicating the complete application (including the functional component) on each user’s workstation [10, 17]. However, not all applications can be replicated without causing undesirable behavior. To illustrate, consider again the example application. Assume that the functional component mails the new grades to the users of the class in response to a change to the cutoff scores. Replicating the functional component would cause a grade to be mailed multiple times to each student, once by each of its replicas. Moreover, performing functional computations multiple times can be inefficient when these computations are expensive. For this reason, multiuser Suite supports physical separation of the semantic object and its dialogue managers into different, possibly remote address spaces. The creator of the semantic object decides where it executes and each user decides where his dialogue manager executes. Transactions User interface and functional components must communicate with each other using transactions. A few single-user UIDEs such as Serpent [2] support transactions between the userinterface component and the functional component, that is, allow each component to send a sequence of actions as one unit to the other component. Transactions are important in the single-user case since they prevent a component from performing spurious actions in response to incomplete information received from the other component. To illustrate, consider what happens when user pd makes a sequence of changes to cutoff scores. In the absence of support for transactions, the functional component would recompute and mail the grades on every one of these changes. Transactions are even more important in the multi-user case. They prevent a user from seeing uncommitted changes made by other users. Moreover, when a user-interface component and a functional component are distributed, they (a) allow a sequence of actions to be sent from one component to the other component in a single message instead of multiple messages and (b) provide failure atomicity. Continuing with the example, consider what happens when user pd makes a sequence of changes to the cutoffs. Transactions allow user pd to postpone communication of the new cutoff scores to other users until he commits the sequence of changes. Moreover, they reduce the number of messages communicated among the distributed components. This principle allows a particular component to communicate the same changes to different components at different times. For instance, the user-interface component of user pd may commit a sequence of changes to the user-interface component of user rxc incrementally but to the functional component as one unit. The principle only advocates that each component have the option of sending a sequence of related actions to another component in a single transaction. It does not indicate how these changes are grouped. Collaboration -Transparent and -Aware Programs A multi-user UIDE must support collaboration-transparent programs. Collaboration-transparent programs [19] are multi-user programs that are completely unaware of the fact that they are interacting with multiple users. By supporting such programs, a multi-user UIDE offers automation since it relieves application programs from performing their collaboration tasks, that is, those tasks that must be performed to allow more

than one user to interact with these programs. These tasks include multiplexing output to and demultiplexing input from multiple users, sharing interaction objects among users of the program, and enforcing access control and concurrency control. Supporting collaborationtransparent programs is particularly useful when the multi-user UIDE is an extension of an existing single-user UIDE, since it allows existing single-user programs written for the latter to be used by multiple users. For these reasons, multi-user UIDEs such as VConf [17], Rapport [10], and multi-user Suite [8] support collaboration-transparent programs. Naturally, it is possible to offer different rules for defining the semantics of these programs. For instance, the Rapport and VConf collaboration-transparency rules support WYSIWIS multiuser interaction while the Suite rules support WYSINWIS interaction. This principle does not preclude supporting collaboration-aware programs, that is, multi-user programs that exercise control over the way their collaboration tasks are performed. It only requires that the UIDE give application programmers the option of developing collaboration-transparent multi-user programs. In fact, we believe that a multi-user UIDE must also give them the option of developing collaboration-aware programs: A multi-user UIDE must support collaboration-aware programs. Different multi-user programs often have different collaboration needs. For instance, a multi-user document editor may want each user to have the same access to each part of the document while a multi-user talk program may want each user to modify only his message. By supporting collaboration-aware programs a UIDE can give application programmers the flexibility of tailoring the collaboration to their needs. For this reason, Colab [27], Rendezvous [22], and multi-user Suite [8] all support such programs. The two principles above require that a UIDE support both collaboration-aware and collaboration-transparent programs. One simple approach to supporting both kinds of programs is to offer a single predefined collaboration scheme for handling the various aspects of collaboration and low-level primitives for implementing application-defined collaboration schemes. The former would allow the UIDE to support collaboration-transparent programs while the latter would allow it to support collaboration-aware programs. This approach, while simple to design and implement, makes the cost of developing collaboration-aware programs very high since it requires that they use low-level primitives for handling all aspects of the collaboration. Therefore, we advocate the following: A UIDE must offer application-programmers primitives for incrementally and independently overriding the various aspects of the default collaboration scheme defined by the UIDE. This principle supports the goal of iterative development since it allows an application program to become incrementally aware of the different aspects of collaboration. For the reasons given above, multi-user Suite supports all three of these principles. It defines a large number of methods for handling various aspects of collaboration; offers collaboration-transparent programs default methods for handling these aspects; and offers collaboration-aware programs primitives for incrementally overriding the default methods.

Collaboration -Transparent and -Aware User Interface Multi-user programs must offer collaboration-transparent user interfaces. A collaboration-transparent user interface is a multi-user user interface that does not make users of it explicitly aware of the fact that they are interacting with a multi-user program. In particular, it does not display any information or require the use of any command that is not useful in the single-user case. The example multi-user user interface of Figure 1 is an example of such a user interface. It does not display any information regarding collaboration and allows a user to interact with the program without using any multi-user command. By supporting such user-interfaces a system can support multi-user programs without increasing the overhead of using them. Users of a collaboration-transparent user interface may in fact be aware that they are interacting with multi-user programs. Continuing with the example, user pd will deduce that another user is also interacting with the program if user rxc changes the cutoffs. However, the user interface is still collaboration-transparent since it does not provide any explicit information regarding the collaboration. A desirable corollary of the principle above is that: A multi-user program must offer a user interface that makes a single-user of the program completely unaware of the fact that he is interacting with a multi-user program. An important dual of this principle is: Multi-user programs must also offer collaboration-aware user interfaces. A collaboration-aware user interface is a multi-user user interface that displays information and offers commands that are not necessary in the single-user case. Such a user interface can offer several benefits. It can inform users about activities of other users, thereby preventing conflicts and reducing the problem of concurrency control modes described earlier. For instance, Colab [27] allows a user to see the pointers of other users, GROVE [9] puts ‘‘clouds’’ around objects being modified by other users, and GroupDesign [3] creates an audio echo to indicate to a user that another user is working on a nearby interaction object— the loudness of the sound indicates how far the remote user is. Moreover, a collaboration-aware user interface can provide special discussion channels such as the DCS discussion windows [21] for informal discussion and the SCS issue nets [14] for formal and informal discussion. Furthermore, it can provide special collaboration commands allowing users to, for instance, lock some data structure. Finally, it can allow users to tailor the collaboration method defined by the program to their needs. For instance, multi-user Suite allows each user to specify how correct a value must be before it is transmitted to other users [7]. A collaboration-aware user interface is particularly important when the application program is an existing single-user—and hence collaborationtransparent—program since it gives the users the flexibility of tailoring the default collaboration method provided by the UIDE. A multi-user program must offer end-users primitives for incrementally overriding the various aspects of the collaboration scheme defined by the program. This principle is similar to the rule given in the previous section for overriding the various aspects of the default collaboration scheme supported by the UIDE. In fact, multiuser Suite offers end-users the same primitives for changing the collaboration scheme

specified by an application program that it offers application programs for overriding the default collaboration scheme defined by the UIDE. This principle allows users to incrementally trade low interaction overhead for functionality. A corollary of this principle, which is a well-accepted user-interface principle, is that: Multi-user interfaces must support end-user customization. Multimedia A multi-user program must offer multimedia support for coordinating the activities of the participants and annotating shared objects. Audio and video conferencing can help users coordinate their activities by simulating aspects of face-to-face interaction. Moreover, in a multi-user environment, they can be more effective than text/graphics for annotating documents [11]. Continuing with the example of Figure 1, multimedia support allows users pd and rxc to debate the merits of changing a cutoff score using a video/audio conference and annotate a changed cutoff with an audio comment describing why the cutoff was changed. For these reasons, CAVECAT [20] allows users to see video images of other users and SuiteSound [25] supports audio annotations and conferencing. Hierarchical Abstraction Representation User interface processes must keep hierarchical representations of the underlying abstractions. As pointed out in [28], in the single-user case, hierarchical representations allow user interface processes to (a) show users the structure of the abstractions; and (b) do input correlation, that is, map cursor positions to the data they select. In the multi-user case, they offer several additional benefits. They reduce the cost of physical separation since they allow user interface components and functional components to exchange values of abstractions instead of their typically much larger visual representations. For instance, they allow the user interface and functional components of the example application to exchange values of cutoffs instead of their graphical presentations. Moreover, since these representations are hierarchical, they allow these components to communicate only those parts of the abstractions that change. For instance, they allow the user interface component to send the value of the cutoff score that changes instead of the whole list of cutoffs. Furthermore, they allow the user interface components to offer commands for annotating arbitrary parts of the underlying abstractions. For instance, they allow the user interface components of the example application to offer commands that let the users annotate either a particular cutoff or the complete list of cutoffs. Finally, they allow these processes to offer fine-grained collaboration methods. For instance, they allow the user interface process of user pd and rxc to allow a cutoff to be modified by any user but a comment only by the creator of that comment. For these reasons, Suite dialogue managers keep hierarchical representations of the abstractions defined by the semantic object.

UIMS Support for Collaboration Collaboration tasks must be performed by the UIMS—the highest layer of a user interface component. Typically, a user interface component has a layered architecture consisting of a window system, a toolkit, and a UIMS (User Interface Management System [24] ). Which of these layers should perform the collaboration tasks of the application? Several systems such as VConf [17], Rapport [10] and [1] perform the collaboration tasks in the lowest layer— the window system. We advocate the opposite approach of performing these tasks in the highest layer—the UIMS. The intuitive motivation for this principle is that the higher the user interface layer the more intelligently it can perform the various collaboration tasks. Consider first the task of sharing interaction objects among multiple users. A higher layer can access a richer set of interaction objects since it can access the interaction objects defined not only by it but also the ones managed by lower layers. As a result, it can give users better choices in choosing the interaction objects they share. For instance, a window system can give users the the option of completely sharing or not sharing a window while a UIMS can also give them the option of sharing presentations of the abstractions displayed in a window (without sharing the other properties of windows such as window sizes and scrollbars), since presentations of abstractions are interaction objects defined by the UIMS layer. Now consider communication of values of interaction objects among users that share these objects. Unlike a window system, a UIMS can check the value for semantic correctness before transmitting it [7]. Finally, consider concurrency control, access control and supporting annotations. Only a UIMS can support fine-grained concurrency control, access control, and annotations since layers lower than it do not keep hierarchical representations of abstractions. Multi-user Suite and Rendezvous are examples of systems that handle collaboration in the UIMS layer.

3. CONCLUSIONS AND FUTURE WORK The current multi-user systems have adopted a wide range of approaches. For instance, some systems such as VConf [17], Rapport [10], and [1] handle collaboration in the window layer, while others such as Rendezvous [22, 23] and multi-user Suite [7, 8] handle it in the UIMS layer; some systems such as VConf and Rapport support only collaboration-transparent programs, while others such as Colab [27] and Rendezvous support only collaboration-aware programs; and some systems such as Rendezvous and multiuser Suite support concurrent command processing while others do not. It is easy to conclude from this scenario that there are few fundamental principles in designing such systems. The main thesis of this paper is that a significant number of such principles exist. Not all of these principles are orthogonal. In fact, several principles are prerequisites for other principles. For instance, supporting logical separation is a prerequisite for supporting concurrent command processing and physical separation; and supporting hierarchical representations of abstractions in a UIMS enhances multi-user interaction only when the UIMS handles collaboration. Such principles can be considered more fundamental than the principles they support. Table 1 shows the dependencies among the various principles and

the benefits of supporting each one of them. The paper contains an important lesson for designers of multi-user systems: They should not ignore principles of designing single-user systems. Some of these principles are well-accepted principles of designing single-user systems that have in fact been ignored by several designers of multi-user systems. Consider the principle of logical separation. To the best of our knowledge, multi-user systems other than CES, GROVE, Rendezvous, and multi-user Suite have ignored this principle. As a result, these systems cannot offer the benefits of WYSINWIS interaction, concurrent command processing, and physical separation. Conversely, the paper also holds an important lesson for designers of single-user systems: Following good principles of designing single-user systems often allows these systems to better support multi-user interaction in the future. Several of these principles such as the principle of multiple/dynamic linkage and transactions are good but not well-accepted principles of designing single-user systems. The paper presents new motivation for these principles from the multi-user perspective, thereby showing that it is crucial to support these principles in a single-user system that may in the future support multi-user interaction. Most of these principles describe the functionality and architecture of a multi-user program. These are subjects that are of concern to both designers of multi-user programs developed from scratch and UIDEs that automate the construction of multi-user programs. Several of these principles, however, are difficult to implement. For instance, the principles suggesting support for both collaboration-aware and collaboration-transparent user interfaces require the implementation of multiple user interfaces per functional core. As a result, following these principles makes the task of implementing multi-user programs from scratch Table 1 22222222222222222222222222222222222222222222222222222222222222222222222 Benefits 2Principle 2222222222222222222222222222222222222222222222222222222222222222222222 Logical Separation WYSINWIS, concurrency, physical separation Multiple, Dynamic Linkage dynamic collaboration groups, WYSINWIS Mixed Control flexibility, prevent conflicts Multi-Thread Dialogues mixed control, concurrent cmd. proc. Concurrent Command Processing prevent starvation, concurrency Physical Separation UI independence, local response Transactions prevent spurious actions, atomicity, efficiency Collaboration Transparent Programs automation Collaboration Aware Programs flexibility Incremental Awareness iterative development Collaboration Transparent UI reduced multi-user overhead, compatibility Collaboration Aware UI coordination Incrementally Aware UI flexibility Multimedia coordination, annotation Hierarchical Abstraction efficiency, fine-grain collaboration control Collab. Support flexibility, hierarchical abstraction 2UIMS 2222222222222222222222222222222222222222222222222222222222222222222222

more difficult, which underscores the importance of developing general-purpose multi-user UIDEs that automatically satisfy these principles. The paper has been titled, ‘‘Principles of Designing Multi-User User Interface Development Environments,’’ to emphasize that we expect these principles to be met by designers of UIDEs and not individual multi-user programs. None of these principles are mandatory, that is, required to support multi-user interaction. In fact, to the best of our knowledge, no multi-user program/UIDE currently supports all of these principles. Multi-user Suite supports most but not all of of these principles—it does not currently support, for instance, video. These principles can be used to evaluate the capabilities of current multi-user systems—a system that does not support some of these principles cannot offer the associated benefits. These principles are abstract principles in that they have several concrete implementations. For instance, the principle advocating support for collaboration-transparent programs does not specify the semantics of these programs. Some of the other questions left answered by this paper are: What kind of concurrency control and access control mechanisms should a multi-user system support? What kind of information and commands should a collaboration-aware user interface support? Should a heavyweight user interface process consist of multiple communicating lightweight processes? Further research is necessary to identify, evaluate, and implement alternative approaches to meeting these principles. Further research is also necessary to study additional consequences of supporting these principles, determine if there are good single-user principles that are not good multi-user principles, and identify new multi-user principles and the benefits of supporting them.

4. ACKNOWLEDGMENTS Ronnie Martin and Rajiv Choudhary gave useful suggestions for improving the presentation of this paper. This research was supported in part by National Science Foundation grant IRI-9015442 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). 5. REFERENCES 1.

H.M. Abdel-Wahab, S.U. Guan, and J. Nievergelt, Shared Workspaces for Group Collaboration: An Experiment using Internet and UNIX Interprocess Communications, IEEE Communications Magazine 26(11) pp. 10-16 (November 1988 ).

2.

Len Bass, Erik Hardy, Reed Little, and Robert Seacord, Incremental Development of User Interfaces, Proceedings of IFIP TC2/WG 2.7 Working Conference on Engineering for Human-Computer Interaction, Napa Valley, August 1989, pp. 155-176 NorthHolland, (1990).

3.

Michel Beaudoin-Lafon and Alain Karsenty, Transparency and Awareness in a RealTime Groupware System, Rapport de Recherche no. 704, University de Paris-Sud Centre d’Orsay Laboratoire de Recherche en Informatique (October 1991).

4.

Joelle Coutaz, Architecture Models for Interactive Software: Failure and Trends, Proceedings of IFIP TC2/WG 2.7 Working Conference on Engineering for HumanComputer Interaction, Napa Valley, August 1989, pp. 137-154 North-Holland, (1990).

5.

Joelle Coutaz and Sandrine Balbo, Applications: A Dimension Space for User Interface Management Systems, Proceedings of the CHI’91 Conference, pp. 27-33 (April 1991).

6.

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

7.

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

8.

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

9.

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

10. J.R. Ensor, S.R. Ahuja, D.N. Horn, and S.E. Lucco, The Rapport Multimedia Conferencing System: A Software Overview, Proceedings of the 2nd IEEE Conference on Computer Workstations, pp. 52-58 (March 1988). 11. J. Galegher and R. E. Kraut, Computer-Mediated Communication for Intellectual Teamwork: A Field Experiment in Group Writing, Proceedings of the ACM Conference on Computer Supported Cooperative Work, pp. 65-78 (October 1990). 12. Mark Green, A Survey of Three Dialogue Models, ACM TOG 5(3) pp. 244-275 (July 1986). 13. Irene Greif, Robert Seliger, and William Weihl, Atomic Data Abstractions in a Distributed Collaborative Editing System, Conference record of POPL, (January 1986). 14. Matti Hamalainen, Safaa Hashim, Clyde W. Holsapple, Yongmoo Suh, and Andrew B. Whinston, Structured Discourse for Scientific Collaboration, Journal of Organizational Computing, (to appear). 15. H. Rex Hartson and Deborah Hix, Human-Computer Interface Development: Concepts and Systems, ACM Computing Surveys, pp. 5-92 (March 1989). 16. Keith A. Lantz, William I. Nowicki, and Marvin M. Theimer, An Emperical Study of Distributed Application Performance, IEEE Transactions on Software Engineering 11(10)(October 1985). 17. Keith A. Lantz, An Experiment in Integrated Multimedia Conferencing, Proceedings of Conference on Computer-Supported Cooperative Work, pp. 267-275 (December 1986). 18. J. Chris Lauwers and Keith A. Lantz, Software Architectures for Collaborative Systems, Personal Communication (1988). 19. J.C. Lauwers and K.A. Lantz, Collaboration Awareness in Support of Collaboration Transparency: Requirements for the Next Generation of Shared Window Systems, Proceedings of ACM CHI’90, pp. 303-312 (April 1990).

20. 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, pp. 203-208 (April 1991). 21. R. E. Newman-Wolfe, C. L. Ramirez, H. Pelimuhandiram, M. Montes, M. Webb, and D. L. Wilson, A Brief Overview of the DCS Distributed Conferencing System, Proceedings of the Summer Usenix Conference, pp. 437-452 (June 1991). 22. John F. Patterson, Ralph D. Hill, Steven L. Rohall, and W. Scott Meeks, Rendezvous: An Architecture for Synchronous Multi-User Applications, Proceedings of the Conference on Computer-Supported Cooperative Work, pp. 317-328 (October 1990). 23. John F. Patterson, Comparing the Programming Demands of Single-User and MultiUser Applications, Proceedings of the 4th ACM SIGRAPH Conference on User Interface Software and Technology, pp. 79-86 (November 1991). 24. G. Pfaff, User Interface Management Systems, Springer Verlag, Englewood Cliffs, NJ (1985). 25. J. Riedl and V. Mashayeki, Continuous Media in Discrete Objects: Multimedia for Computer Supported Collaborative Work, Proceedings of 1992 Workshop on Multimedia Information Systems, (February 1992). 26. Hikmet Senay, Piyawadee Sukaviriya, and Lucy Moran, Planning for Automatic Help Generation, Proceedings of IFIP TC2/WG 2.7 Working Conference on Engineering for Human-Computer Interaction, Napa Valley, August 1989, pp. 293-312 North-Holland, (1990). 27. Mark Stefik, Gregg Foster, Daniel G. Bobrow, Kenneth Kahn, Stan Lanning, and Lucy Suchman, Beyond the Chalkboard: Computer Support for Collaboration and Problem Solving in Meetings, CACM 30(1) pp. 32-47 (January 1987). 28. Michal Young, Richard N. Taylor, and Dennis B. Troup, Software Environment Architectures and User Interface Facilities, IEEE Transactions on Software Engineering 14(6) pp. 697-708 (June 1988).