containing a central daemon. Because of this we have chosen a client-server model for our access control system, where an application will contain an access ...
Access as a Means of Configuring Cooperative Interfaces Gareth Smith and Tom Rodden Lancaster University, Lancaster, LA1 4YR, U.K. Email: {gbs, tom}@comp.lancs.ac.uk Phone: (+44) 524 65201
ABSTRACT
The emergence of CSCW has seen the development of a number of applications which simultaneously present a number of interfaces to a community of users. Limited consideration has been given to the provision of facilities that support the configuration and tailoring of these cooperative user interfaces. This paper presents a simple mechanism that enables dynamic support for tailoring user interfaces. Rather than focus on the interface as having been derived from a set of shared objects, we choose to view the problem as one of a shared interface constructed from a collection of interface objects and access to this shared interface. This paper presents an access model and an environment that facilitates the construction and runtime support of cooperative user interfaces. KEYWORDS
Multi-user Interface Development Environment, Access control, User Interface tailoring, CSCW Architectures. INTRODUCTION
The user interface to a computer application has been seen from a purely personal perspective until relatively recently. The general model was of an application providing a single interface through which a user interacted. However, the emergence of CSCW has seen the development of a number of applications which simultaneously present a number of interfaces to a community of users. Different researchers have investigated techniques and architectures which support the real time presentation of these interfaces. The majority of this research has focused on the development of techniques and facilities to coordinate and manage interaction across the different interfaces. In particular, cooperative applications have been considered as either collaboration-transparent or collaboration-aware [11].
Permission to copy without use all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.
Collaboration-transparent applications are unaware that more than one interface is presented to users. Since the application may only interact with one user at a time, this approach is reliant on the use of a floor control policy to coordinate interaction. In contrast, Collaboration aware applications are devised to interact directly with a number of users by presenting a number of different interfaces. Collaboration aware applications can provide user interfaces with features that are not possible in a collaboration transparent application. Such features include the provision of alternative views and the removal of any reliance on an explicit floor control policy. The need to tailor individual user interfaces is generally accepted in the areas of single and multiple user interfaces [9]. However, only limited consideration has been given to the provision of facilities that support the configuration and tailoring of cooperative user interfaces. This paper presents the development of a set of facilities which allow the configuration and tailoring of multi-user interfaces. The approach taken is to view the various interfaces provided by cooperative applications as derivatives from a shared interface rather than different independent interfaces. The different individual access properties to this shared interface can be configured and controlled by a simple access model to provide a variety of different interfaces. BACKGROUND AND MOTIVATION
Early real-time, multi-user interface applications implemented strict What You See Is What I See (WYSIWIS), where each user saw exactly the same image of the application. Architectures, such as SharedX [10] provided WYSIWIS by simply multiplexing the input and output of an existing single user application. However, several applications supporting WYSIWIS [18], were assessed in the Colab [19] meeting room at Rank Xerox and found to be limited. In fact, Stefik [18] concluded that “WYSIWIS is too inflexible, if strictly interpreted, and must be relaxed to better accommodate important interactions in meetings”. Collaboration-aware user interfaces emerged which allowed a number of users to collaboratively interact through different user interfaces. For example, the provision of public and private views, where certain parts
of a user’s interface can be seen only by that user (private or personal), whereas others may be visible by all users (public). Provision of such views permits a control over sharing of information. Patterson [14] states “The essence of multi-user applications is sharing and control over sharing”. Further control over sharing is shown in Grove [4], where a common view is implemented, as well as a public and private. We wish to focus on the provision of facilities to support the sharing of multi-user interfaces across a user community. The use of different views of shared elements has emerged as a definite theme within CSCW interfaces. Private or personal views are supported in a number of recent systems such as Suite [2], Liza [7] and CES [15]. A number of architectures also exist, [14, 1] which support these views through the use of an underlying object model. The model maintains a clear logical separation between a shared object and its views, and separate individual user interfaces are derived from the underlying object. This model, where interfaces are projections of shared objects, provides a considerable amount of control over individual user interfaces and the sharing of information. Complex models are required to support tailoring and configuration within these systems. For example, in the Rendezvous system, the way in which each user interface displays the state information of the underlying object is decided by the application program. This limits the range of tailoring, because all control over user interface modification must be made by the application developer, and it is difficult to predict the nature of user interfaces in advance. An alternative architecture proposed by Bentley [1] increases the range of tailorability by placing a user display agent between the underlying objects and a user’s display. The agent allows dynamic specification over individual displays to be made by the application developer or the end user at any time. This architecture again assumes a shared object and provides it with a number of separate views and the specification of these views requires a considerable understanding of the structure of the shared objects. In this paper we present a simple mechanism which enables dynamic support for user interface tailoring. Rather than focus on the interface as being derived from a set of shared objects we choose to view the problem as one of a shared interface constructed from a collection of interface objects and access to this shared interface. Simple access models are used in only a few collaborative systems, such as RTCAL [8], Suite [2] and Grove [4]. In fact, Shen [16] highlights the need for access control in collaborative systems in general and argues that “most collaborative systems give all collaborators the same rights to all objects and expect access to be controlled by some social protocol”. However, more generally, access models are well understood within multi-user computing systems. Access models have been successfully used for many years to
“tailor” a user's control over information in a number of multi-user systems, such as operating systems and databases. We therefore propose to exploit the concepts within access models to control the tailoring and modification of graphical user interfaces in groupware applications. Thus we view a multi-user interface as a collection of users simultaneously accessing a shared interface. The means by which that access is configured and controlled provides us with a well-understood mechanism for tailoring the cooperating user interfaces. APPROACH
We are currently developing an environment based on the X-Windowing system [17], which allows user interfaces to groupware applications to be defined and constructed. The environment needs to provide facilities to support run-time interface specification and tailoring during development. We also wish to provide facilities to allow tailoring of individual user interfaces through the provision of a simple generally understood mechanism. The basis of our approach is to consider the user interface as a collection of different user interface objects. Each interface object has specific interaction properties and knows how it may be presented to users. Each of these objects is collaboration aware and can present itself to a number of users' displays in different ways. A selection of these objects, termed User Interaction Objects (UIO) within our system, have already been defined and constructed. The use of collections of objects to construct user interfaces is not in itself novel and has previously been applied by a number of researchers. The most notable example of this approach to user interface construction has been Garnet [13]. In Garnet two types of user interface objects are defined: gadgets and interactors. Gadgets are visual user interface objects, such as buttons and text fields. Interactors however, “are encapsulations of input device behaviours”. For example, a menu-interactor is used for choosing one or more items from a set. Interactors are not associated with a particular image, allowing a number of different gadget sets, such as in Motif, NeXT and Macintosh environments to be used. In our system User Interaction Objects resemble Garnets’ interactors, and we use the Motif Widget set as our Gadgets. Each UIO is a C++ object, and existing UIOs are contained within a library. UIOs exist in a hierarchy, where features are inherited down the tree of objects. New objects may be defined that inherit the features of those already constructed. A newly created UIO may then be used in new applications developed with our environment. UIOs control each derived image of its encapsulated interaction technique. For example, a text field UIO may be asked to show itself to three users in varying ways. One user may see and edit it, while the other two may only view the text, as in figure 1.
User A Visible and Editable
Hello
User B Visbile only
Hello
User C Visible Only
Hello
Presentation Text Field UIO
general model there exists a set of passive Objects which are the resources to be protected, and a set of active Subjects who wish to access these objects. Each Subject, Object pair (S, O) is associated with an access right(s). An access right is a privilege that a subject (S) has over an object (O). A Subject may access an object in a way specified by the access right(s) held by the pair (S, O). A number of more specific models are derived from the Access Matrix including: •
Capabilities, which divide the matrix into columns, each user holds a list of accessible objects. The addition of a new object requires each user’s access list to be updated.
•
An Access control list, in which the matrix is divided into rows, and each object holds a list of users who may interact with it. It is difficult for a user to tell which objects they may use. Addition of a new user requires all objects to update their lists, and the list of users able to access an object may become large.
Figure 1: A text field UIO and three representations
User Interaction Objects have a set of interaction properties which they may exhibit; for example, they may be selected, moved or resized. Interface objects know how to present themselves to different users through an access control system. UIOs have a varying number of permissions that allow a user to access different interaction properties. For example, a user of a text field UIO could have “Visible” and “Editable” permissions allowing the user to see and alter the text object. Because UIOs are arranged in a hierarchy each UIO may inherit a number of permissions from more abstract objects.
Although the access matrix defines the principal model for the control over a user’s (or subject’s) access to an object, it faces a number of problems when used in a multi-user collaborative environment. Shen [16] highlights these problems with the above model :
User Interface Tools
Tools or applications in our environment are built in a similar manner to client programs in the X Window system. Structurally the application is similar to a normal X client, with the addition of a Display Manager (figure 2). The Display Manager is used to set up the user interfaces, and contains an abstract definition of a common interface provided by the application. This abstract definition is used by an access client to derive alternative interfaces for different users. The application developer or end-user is not concerned with this component because it provides the mapping between users and the UIOs of the application.
Display Manager Access Client Heirarchy of UIOs Event-Callback Mapping
Application Code (Callbacks) Figure 2: Structure of an application ACCESS MODELS
Access control is widely used within computing systems and many access models exist [5], most of which are derived from the Access Matrix Model [12][6]. In this
• It does not facilitate the use of roles or groups; individual users must be used. • It does not facilitate easy specification of access rights • It does not offer a mechanism for specification of the access matrix, or for access checking Shen and Dewan [16] forward an access control model to solve some of these problems. This model provides us with a number of useful innovations. But the model they define does not directly support our needs. The semantics of the rights are embedded within the model, and they are not extendible. Their model is also heavily associated with the Suite framework. We have developed a simple access control model, that includes many of the features mentioned by Shen and Dewan, but we believe with a more generic approach. We have included this model into a multi-user user interface environment, to control individual user interfaces. In this way it is similar to Shen and Dewan’s Ctool example, but we take a different approach based upon mapping different interactional properties of objects to cooperating users. Our Access Model
Our access model contains the following elements • User (U). The user of a system • Role (R). A group containing a number of users • Object (O). A resource to be protected • Permissions (P). A specification on how a user may access an object
Figure 4: Permissions of “The button” for three users
These are common to the majority of access models. A role is used to group together a number of users, and it may define a user’s status. In simple access models, the permissions are simply true and false, that is a user may or may not have access to that object. In graphical user interfaces the patterns of access are richer. For example, a user may see but not select a button. As a result we need to also specify how a user may access a particular object within the set of permissions. Unlike many models using a fixed set of permissions, such as Read, write, Edit, etc., our model facilitates an extendible matrix to specify permissions. Our permissions not only state the access a user has to an object, but also specifies how an object is shared among users. Each object may have a number of methods describing its interactional properties that may be invoked on it, for example, a button on a user interface may be visible, pressed, moved and resized. Access to each of these methods by a user may be specified within a permission matrix. Object Shared
User
Methods
Access
Permission Matrix
Figure 3: An Object and permission mapping to a user in our system
The permission matrix for an object consists of a list of methods associated with that object. For each user the permission matrix records if the user can invoke that method. A second column in the permission matrix state whether the result of method invocation is to be shared, that is, if the result of applying a method by one user is to be propagated to others. Each object has a permission matrix for each user, (figure 3). We use flags as entries in the permission matrix because they are simple, flexible, semantically light, and extensible. No set of permissions is enforced by the access model, the semantics are defined
behind each flag by the system implementing the access model. As an example of functionality, consider three users, and a single button. The button has the methods Visible, Usable, Moveable and Resizeable. The interfaces of the button have been configured as in figure 4. We can see from this figure that all three users may see the button. The visible method is not shared in our system, as accessing and sharing the visibility of the button are identical in our case. Below the visible method are each users’ access and sharing permissions. From figure 4, we see that the button may be pressed (Usable) by Tom and Jon, but not Andy, and that Tom and Andy are sharing this method’s actions. So if Tom presses the button, Andy will see the button be depressed, but Jon will not. Likewise, if Jon pressed the button no one else will be informed that it has been pressed. Similarly if Tom resized his button, this would not effect any other buttons, but if Jon resized his button, Andy’s would also resize. This allows different levels of detachment to be specified for shared interfaces. Finally, if Tom or Jon moved the button, both theirs and Andy’s button would move. In our system we can have a number of multi-user applications running simultaneously in an environment containing a central daemon. Because of this we have chosen a client-server model for our access control system, where an application will contain an access client and the daemon will hold our access server. A client invokes a request to the server by either passing a pair (O, U) where O is the name of the Object that is being accessed and U is the name of the User wishing access. In our system (O) is an individual UIO, and (U) is a user of the system. The access request call is used to gain a user’s permissions over an object. The access server returns this call with (P), where P is a matrix of access and sharing permissions An access client may also pass the pair (U, R) to the server, where U is the name of a User and R is a role. Roles are used to define a user’s state. For example, a user may be a member of the role lecturer, stating that this user is a
lecturer. This user may also be a member of a more dynamic style of role, such as writing. The use of this type of role allows a sense of context to be used. For example, one object may add the user (U) to the role writing while some operation is in effect. Other objects may only allow themselves to become active if that user is a member of this writing role. The call above can be used, by passing the pair (U, R) to the server, to check if a user is a member of a role; to add a user to a role or to remove a user from a role. Each entry in our implementation of the permission matrix holds one of four states -
Structured class UIOs have a dynamic and extendible set of methods. For example, in a list of items the list has a set of common methods and each list member has the methods visible and usable associated with it. Since list elements have the methods visible and usable associated with them for every element we extend the permission matrix by two rows. Each element’s usable method may also be shared, allowing other users to see when an entry is selected. We also extend the permission matrix in the same way for menu UIOs. Compare the permission matrices of a button and a menu with two items :
• Always True. Here a UIOs permission is always available, for example always visible. The end-user may not alter this permission of this UIO. • Always False. As above, the application developer has chosen not to allow an end-user to alter this permission of this UIO, but in this case the permission never becomes available. • Default true, but may be changed to false by the enduser. Currently set to true, the end-user may modify this particular permission of the UIO. • Default false, but may be changed to true by the end-user. This becomes the state of the permission of the UIO if an end-user has chosen to make it false from a true state (the one above). This effectively gives us two levels of specification. One where the application developer or privileged user may force fixed permissions of a UIO for a user. For example, to specify a case such as “this user must always see this button, but may never press it”. The second level is for end-user tailoring, where, if a permission is set to either one of the two latter states in the above list, the user may toggle between them. The permissions, visible, usable, moveable and resizeable are sufficient for the majority of the UIOs defined so far. As further UIOs may be added, the four permissions may not be sufficient to cover all the features offered by the new UIO. The addition of new permissions for new UIOs is a simple matter of creating additional permission flags for that UIO. A UIO class defined as structured uses this extendible feature. From this virtual class are derived lists and menu UIOs. With only the four permissions defined above, no access control is available over the contents of any structured UIO. Dewan [3] reasons that control over individual interfaces should be as fine grain as single lines in an editor. Structured UIOs allow fine grain control of their contents for each user, through the dynamic nature of the permission list. It is impossible to specify the individual permissions on the contents of a list on a per class basis, as each instance is likely to be different. For example, not all menus will have the same number of entries. Therefore control over the contents of structured UIOs must be at a per instance level.
A button
A menu with two methods
Figure 5: Example of instance specific permissions Dynamic Creation of Objects and Run-time issues
Many applications dynamically create interface objects and it is feasible for an application to desire the “creator” of an instance of an object to gain or loose certain permissions. For example in a multi-user drawing application we may wish to specify that an object may only be deleted by its creator, but we will not know beforehand who created which object. We have defined a special role called “CREATOR” to facilitate this. For example, an access specification for an object, which spawns instances of itself at run-time may include the role creator (with certain permissions). For a particular instance, the user replaces the creator role inheriting the permissions set for that role. In order to increase the flexibility over access control specification, and to overcome some difficulties we extend the services provided by the access model. First we provide the role “ALL”, which removes all access restrictions from an object. We also include a negative role feature. Here a role or user may be prefixed by a minus (-) sign. Then that user or role is removed from the access permission list of that Object if the user or role was already specified. With the notation we have above, there may be access conflictions. For example, for a particular UIO, we may allow access to everyone except Andy. This may be written as “-Andy, ALL”, but as Andy is a member of the ALL role, is he allowed access to this UIO?
We do not wish to use a fixed protocol over access priority, such as ‘any role or users preceded by a “-” override anything else defined’. Instead, like Shen [16], we place the access authority in the order of definition in the list. The first entry having highest authority. For example, “Andy , ALL”, would not allow Andy access to the UIO. But, “ALL, -Andy” would allow Andy access to the UIO.
users as in figure 7 to reflect their positions within our department. Consider an application which simulated a multi-user graphical bulletin board. The board will contain a number of shared notes. To demonstrate the access model a simple application has been constructed that allows the placement of shared “notes” onto a shared board (figure 8).
So far we have ignored the presence of permissions. Each entry in the list may be associated with a set of permissions. Such as in “Andy , ALL ”, Andy gains the union of permissions and . We can use the negative association to provide a permissions mask. For example, in “-Andy , ALL ”, Andy gains the permissions , but looses any permissions specified in . This allows specifications such as “Andy may never move this UIO”, which allows us to specify Andy‘s other permissions elsewhere. It is also possible to associate one object’s list of permitted users and roles with other objects. That is, one object’s access specification may be shared among other objects. For example, in figure 6, the source filename field of an application has a defined access specification, which is also used by the other two fields. As the “pointer” to another object’s permissions is treated as a special role, the other two field objects in figure 6 may also refine the associated specification.
Each participating user sees the shared board and may place notes onto the shared surface. Notes contain text which may be edited at any time. The notes may also be deleted and moved within the shared surface. A note is built from four UIO’s. A base, a title, a text body and a close button which destroys the note, the hierarchy is denoted in figure 9.
Access Specification
Source Filename Field
Figure 8: Example of the multi-note application
Destination Filename Field Comments Field
Base
ּ Figure 6: Linking access permissions Close
Example of Access Model in Use
The access model described earlier is used in our environment. The architecture of which is simply a daemon, containing the access server, a number of users and a number of applications. Each application contains a number of UIO’s defining the user interface, and a single Display Manager which holds an access client. Software Engineering group
tom
is
gordon doug
jonathan andy
Distributed Systems Group
phil Key Staff Bold Students Italics
Figure 7: Roles within an academic department
Now consider as an example a scenario in an academic environment, containing staff and students. We group the
Title
Text body Close
UIO Hierarchy of a note
Example image of a note
Figure 9: Relationship between UIO hierarchy and it’s representation
Instead of defining a large number of notes to be used, and allow users to select blank ones, we allow a note type to be defined. A note type will define the structure and the default permissions for individual users. Instances of this type may then be created. An instance copies the default configuration of structure and permissions. The permissions of the new instance may then be tailored by end users. We have set up the permissions for each object on the note for each user, three example views for three people are shown in figure 10.
Figure 10: Three sample views of the same “note”
The different objects making up the note have an associated permission matrix that allows different permissions to be set for each user. These permissions determine the presentation and interaction properties of the notes. An example of the permissions set for Doug’s title object is shown in figure 11. From this figure we see that the field can be moved by Doug, but this is local to his display and will not be propagated to other users.
Figure 11: Permissions for Doug’s title field THE ARCHITECTURE
Our architecture, Emily, consists of a number of key elements. One such element, the Emily Daemon, is a permanent process. All others such as applications are created and destroyed as required. The diagram below shows the architecture when one user is using one application. This is the simplest state of the environment, a more likely scenario is one of multiple users and multiple applications. The diagram however, shows all the objects in Emily, each of which provides different services
User App. Interface
UserPanel
Emily Daemon
Display Manager
Application
User Interface Construction Other Communication Channels
Figure 12: The Emily Architecture
Object •User •Appln. Interface •User-Panel
•Emily Daemon
•Application •Display Manager
Detail/Service provided A single user of the system The user interface of an application for a particular user The generic control panel provided by the Daemon. It provides : • A list of open sessions of applications and who is using them • A list of applications from which new sessions may be created • A number of preference selectors Co-ordination of activities : • User registration • Present User-Panel to user • User’s permission resolution • Request user interface from an application on a user's behalf • Spawn and destroy applications • Holds permission information on users A multi-user application, being used by one or more users. It contains one or more hierarchies of UIO’s. The pre-written part of an application. It is concerned with user interface construction and its dynamic alteration. It contains an access client, and corresponds with the Emily Daemon, resolving a user's permission to interact with a UIO. Any relevant changes in the access state, are send to the Display Manager by the Daemon. The Display Manager then asks relevant UIO’s to modify themselves in particular user interfaces. Table 1: The main components of the Emily environment
THE ARCHITECTURE IN ACTION
Joining an existing application session.
As multi-user collaborative environments consist of more than one phase, in that a user must register with the system; initiate or join an ongoing application; participate in a session of an application and quit the application, our environment supports multi-user interaction throughout these phases.
The user selects the existing application session from their user-panel. This notifies the Emily daemon of the user's request. If the user has permission to join a session, the daemon sends a request to the display manager of that application on their behalf. This request is for the provision of a user interface for the user, thus including them into the session. This interface is realised with reference to the access specified for that user within the access model.
Stage 1. Registration
Any user wishing to use any applications developed using Emily must first register with the Emily daemon. Then, the user is presented with a “User Panel” by the daemon. This provides the user with a link directly to the system. User
User App. Interface
Registration Registration Confirmation and presentation of User-Panel
Emily Daemon
Figure 13: Initial registration with Emily Stage 2. Initialisation
The user may now browse currently open applications, and do one of two things. They may request to create a new session, or to join an existing one. Creating a new session.
The user simply selects the required application from the list shown on their user-panel. If the user has the correct permissions, a session of that application is initiated by the daemon. Immediately after this, the new session creates an interface for that user.
User Interface Construction Display Manager
Emily ion olut s e Daemon R n issio Perm ion reat C tion lica App
Application Figure 14: Application creation
On joining a session (a new or existing one), each user’s interface is constructed by the sessions display manager, see figure 14. The display manager controls all the user interfaces of a particular application. The display manager acts as a filter, showing or hiding particular features of a user interface as specified within the permission matrix for each object.
Stage 3. Run-Time
The first two stages cover addition and removal of user’s accessing the application and the environment itself. This section considers how the environment operates during normal multi-user interaction. Figure 15 denotes two applications and three users in the Emily environment. One user is using both the applications while the other two are only using one of the two. Each user’s application interface is instantiated by the display manager for the application. The display manager instantiates the application from a template definition with reference to the access details held within the Emily daemon. In addition, although not shown in the diagram below, each user has a User-Panel interface to the Emily daemon. Alterations to access permissions are propagated to display managers which then change the application interfaces to users as necessary. User
User App Interface
User
App Interface
while others interact with the application in a purely collaboration transparent manner. The use of an extendible permission matrix also allows us to easily include features into our UIOs, such as inheritance, where we specify whether a particular inherits the properties of its parent or not. We are currently investigation how to further extend this to specify which permissions are to be inherited. Future work also includes the investigation into scrollbar action and floor control policies. We will also investigate the provision of “deep UIOs”, where the UIO decides what actions to take depending on the state of a number of interaction objects, such as a voting button, where it returns how many buttons were pressed from a maximum value. We also wish to investigate the use of different event handling regimes. For example, the use of attaching “weights” to users wishes, where one user’s action may have priority over others.
App Interface
REFERENCES Emily Daemon
Display Manager
Application
Display Manager
User Interaction
[1]
[2]
Application Premission Resolution
Figure 15: Example of three users and two applications within Emily
[3]
CONCLUSION AND FUTURE WORK
Access control is a tried and tested technique for controlling information sharing. Previous work in the areas of operating systems and databases has derived a number of access models to control sharing. These access models fall short of our requirements for an access control model within our collaborative environment [16]. Our access model is specifically designed for multi-user collaboration. The permission model used enforces no restrictions on context and is extendible.
[4]
[5]
[6] Configuration of user interfaces using access control is both simple and effective. Our access model not only restricts users’ access to objects, but also maintains their preferences. UIOs allow users (if permitted) to dynamically alter their user interfaces with respect to appearance and level of sharing. Our environment may provide us with collaboration-aware user interfaces, which is a desired feature of multi-user applications [3]. Dewan also argues that collaboration transparent user interfaces must be provided. With the use of the propagation field in the permission matrix we may choose the level of collaboration awareness at any time. This allows some users to collaboratively work together
[7]
[8]
[9]
Bentley, R., Rodden, T., Sawyer, P., Sommerville, I. "An architecture for tailoring cooperative multi-user displays." CSCW '92, Toronto, Canada, ACM Press, Dewan P., “A tour of the Suite User Interface Software.” Proc. of the 3rd ACM SIGGRAPH Symposium on User Interface Software and Technology, October 1990, pp 57-65. Dewan, P. "Principles of Designing Multi-User User Interface Development Environments." Proceedings of the 5th IFIP WG2.7 Working Conference on Engineering for Human-Computer Interaction, Ellivuori, Finland. August 10-14, Editor: C. Unger and J. A. Larson, Ellis, C.A., Gibbs, S.J., Rein, G.L. "Design and Use of a Group Editor", Technical report STP-263-88, MCC. September. Goscinski , Andrzej “Distributed Operating Systems - The Logical Design” Addison-Wesley 1991 ISBN 0 201 41704 9. Chapter 11 Resource Protection. Pages: 585-647 Graham G. S., Denning P. J. “Protection: Principles and Practices.” Proc of the AFIPS Spring Joint Computer Conference 1972, Pages: 417-429 Gibbs, S.J. "LIZA: An Extensible Groupware Toolkit." CHI '89 Proceedings, ACM Press, Pages: 29-35. Greif, I., Sarin, S. "data sharing in group work." ACM Transactions on Office Information Systems 19875(2) Pages: 187-211. Greenberg, S., “Personisable Groupware: Accommodating Individual Roles and Group Differences” in Proc. ECSCW 1991. Kluwer Academic Publishers, The Netherlands, ISBN 07923-1439-5.
[10]
[11]
[12] [13]
[14]
[15]
[16]
[17]
[18]
[19]
Gust, P. “Shared X: X in a distributed group work environment”, presented at the 2nd Annual X conference, MIT, Boston, Jan. 1988. Lauwers , J.C., Lantz, K.A. "Collaboration awareness in support of collaboration transparency: Requirements for the next generation of shared window systems." CHI 1990 Proceedings, Pages: 303-310. Lampson B. W. “Protection.” Fifth Princeton Conf on Info. and Systems Sciences, Pages: 437-443 Myers, B.A., Guise, D.A., Dannenberg, R.B., Zanden, B.V., Kosbie, D.S., Pervin, E., Mickish, A., Marchal, P. "garnet: comprehensive support for the graphical highly interactive user interfaces." Computer (USA) Vol: 23 (11 (November 1990)), Pages: 71-85. z Patterson, J.F., Hill, R.D., Rohall, S.L. "Rendezvous: An Architecture for Synchronous Multi-User Applications." CSCW Proceedings, Los Angeles, Pages: 317-328. Seliger, R., “The design and implementation of a distributed program for collaborative editing”. Masters thesis, MIT, Cambridge, MASS., Sept 1985. Also Lab for Comp. Sci. Tech. Rep. TR-350 Shen, H., Dewan, P. "Access Control for Collaborative Environments." CSCW92, Toronto, Canada, ACM Press, Pages: 51-58. Scheifler, R.W., Gettys, J. "The X Window System." ACM Transactions on Graphics Vol: 5 (2), Pages: 79-109. Stefik, M., Bobrow, D.G., Foster, G., Lanning, S., Tatar, D. "WYSIWIS revised: early experiences with multiuser interfaces." ACM Transactions on Office Information Systems Vol: 5 (2), Pages: 147167. Tatar, D.G., Foster, G., Bobrow, D.G. "Design for conversation: lessons from cognoter." Int. J. ManMachine Studies (1991) 34 Pages: 185-209.
