LANCASTER U NIVERSITY An Access Model for Shared ... - CiteSeerX

LANCASTER UNIVERSITY Computing Department

An Access Model for Shared Interfaces

Gareth Smith and Tom Rodden Centre for Research in CSCW Research report : CSCW/8/1994

University of Lancaster 1994. Copying without fee is permitted provided that the copies are not made or distributed for direct commercial advantage and credit to the source is given. For other copying, write for permission to:Computing Department, Lancaster University, LANCASTER, LA1 4YR, UK. Phone: +44-524593041; Fax: +44-524-593608; E-Mail: [email protected]

Smith, Rodden

An access model for shared interfaces

AN ACCESS MODEL FOR SHARED INTERFACES Gareth Smith and Tom Rodden Lancaster University Lancaster LA1 4YR Email: {gbs,tom}@comp.lancs.ac.uk

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 the development of 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 run-time support of cooperative user interfaces.

KEYWORDS : Multi-user Interface Development, 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 one user interacted. However, the emergence of CSCW has seen the development of a number of applications which present a number of interfaces simultaneously to a community of users. 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. Cooperative applications have been considered as either collaboration transparent or collaboration aware [11]. 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

2

Smith, Rodden


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 separation suggested by the classification of applications into either collaboration aware or transparent is often not reflected in the demands of particular applications. Dewan [3] suggests that collaborative user interfaces should contain aspects of both the above categories. Collaboration-aware characteristics to enhance one user’s awareness of another, provide private views and so on, and collaborationtransparency when any users’ interactions may become disruptive to others, or a private workspace is required. MOTIVATION The need to provide facilities to tailor user interfaces is generally accepted in the areas of single and multiple user interfaces [9]. The development of these facilities has required considerable effort even within single user interfaces. In the case of cooperative systems the need to support interfaces across a group make the issues involved considerably more complex. The preferences of one user are not necessarily the same for any others and each user must be able to tailor their interface on an individual basis. However, only limited consideration has been given to the provision of facilities that support the configuration and tailoring of cooperative user interfaces. 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 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 users' 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 [13] states “The essence of multi-user applications is sharing and control over sharing”. Further control over sharing is shown in Grove [4], where a shared view is implemented, as well as a public and private. This view allows a subset of users to access the information held within it. We wish to focus on the provision of facilities to support the sharing of multi-user interfaces across a user community.

3

Smith, Rodden


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. While the run time development model is simple in these systems, complex models are often required to support tailoring and configuration. For example, in the Rendezvous [14] system, the way in which each user interface displays the state information of the underlying object is decided by the application developer using a constraint based approach. This limits the range of tailoring, because control over user interface modification must be initially determined by the application developer, and it is difficult to predict the needs 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. However, the shared objects within MEAD [1] are high level, such as aircraft data, including height, class, orientation etc. MEAD provides each object with a number of separate views, but the specification of these views requires a considerable understanding of the structure of the shared object. The shared objects in MEAD may be described as “heavyweight” compound objects incorporating significant application semantics. The provision of public, private and shared views evident within cooperative user interfaces inherently requires some management of the extent to which portions of the interface are shared. That is, the contents of a public view is shared between users, whereas the contents of a user’s private view cannot be accessed by anyone else. In this situation we have a number of users wishing access to some information, and we need to control this access. We believe that some sort of simple control mechanisms are required to manage the levels of sharing within multi-user interfaces. We wish to provide a mechanism that promotes both i) Support for controlling information sharing, and; ii) support for configuration and tailoring of cooperative user interfaces. We wish the mechanism to allow these features to be modified during development by the application programmer and at run-time by the end-user. Such a mechanism must be powerful to describe detailed access information for each user across many parts of a shared interface. It must also be simple if it is to be used during run-time by the end-user. The principal intent is to manage the collaborative aspects of user interface objects. We view these objects as having simple interface semantics, and not constraining the underlying application regarding their use. These objects include push buttons, text

4

Smith, Rodden


fields, and menus. They provide different levels of information sharing and configuration but do not enforce any specific interaction policies. In essence we seek to maintain a separation between the surface interaction objects and the deeper interaction which is more closely associated with the semantics of the application[23]. 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 manage access to this shared interface. In doing so we seek to gain advantage from the familiar nature of access control within multi-user 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. Exploiting the concepts within access models to manage the tailoring and modification of graphical user interfaces in groupware applications provides us with a well-understood mechanism for tailoring the cooperating user interfaces. 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”. The lack of a generally applicable access model for cooperative systems has resulted in a central component of our work being the development of an access model aimed for tailoring cooperative interfaces. APPROACH A key feature of the SOL (Shared interface-Object Layer) development environment are configurable shared user interface objects. A number of these objects, termed “SOLOs” (SOL Objects) have been defined. Each type of SOLO represents a simple graphical interaction technique, such as a button or text field. An application constructs a user interface from these objects in a similar fashion to the construction of an X-window or Smalltalk interface. In this way a common shared interface of the application is created. The difference between SOLOs and other types of interaction techniques is that each SOLO may represent itself to a number of users. Each SOLO may have many representations of itself, normally one for each user. The objects use an access control mechanism to retrieve information on how each user should see it, how much they may tailor it, and how much their interactions should affect other users. For all the SOLOs we have defined, we have a common set of methods, or operations, that a user may invoke on the representations of that object. A user’s access permission maps directly onto these methods. The methods are : • Use, press, edit etc., this is different for each SOLO; • Move, the ability to reposition the object on the screen;

5

Smith, Rodden


• Resize, the ability to resize the representation. Therefore, a users permission for a button SOLO for example, may specify whether they can press it, move it and resize it. Figure 1 shows a SOLO receiving the access permissions to determine how it should present itself to the two current users. In this example, one user has the usable permission for this SOLO and is allowed to type into their text field. The other user does not have this permission and so is unable to edit the text within the field. Editable

Not Editable

Hello

Hello

Representations

Presentation Access permissions

Text Field SOLO

Figure 1: A text field SOLO and two representations

Because SOLOs are arranged in a hierarchy, each SOLO may inherit a number of permissions from more abstract objects above it. Also, new SOLO objects may be added to the hierarchy and extend the number of methods they inherit. It is also possible to define compound SOLOs, constructed from many SOLOs, and emulate more heavyweight shared objects. Our access permissions also specify how much coupling [22] there is between the user’s representations, i.e. how much one user’s actions affect another. For each access method within the SOLO (use, move and resize), there is also a sharing method. This simply dictates whether the effect of one user using a method on an object (such as moving it) should be portrayed to others. Within each SOLO is an underlying system image (figure 2). This representation of the SOLO is hidden from view. All aspects of this image are shared. If any user sharing some aspect of the SOLO modifies that aspect, then the system image is updated. Likewise, when the system image is modified, relevant user’s display are also changed. For example, in a button SOLO, if one user clicks their button, the system image will also appear clicked. This effect is then broadcast to other users’ representations who also have this method shared.

6

Smith, Rodden


Awareness/Coupling

Representations, one per user

Access information

SOLO

System image Figure 2: Schematics of a SOLO

When a new user joins a current session, an interface is constructed on their behalf. Their image of a SOLO is derived from the system image in accordance with the access permissions of that user. For example, within a SOLO text field the system image will contain some text. A joining user will be given a representation of the text SOLO, and if their access permissions state that they wish to share the contents of the text field, then the text from the system image is copied into the new user’s image. User Interface Tools Applications for use within our system 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 3). The Display Manager is used to set up the user interfaces, it contains an access client to receive information from the server, and an abstract definition of a common interface provided by the application. This abstract definition is used to derive alternative interfaces for different users. The application developer or end-user are not normally concerned with the display manager because it provides the mapping between users and the SOLOs of an application. Display Manager

Access information Heirarchy of SOLOs, constructing a common interface

Event-Callback Mapping

Application Code Figure 3: Structure of an application

7

Smith, Rodden


ACCESS MODELS Access control is widely used within computing systems and many access models exist [5], many of which are derived from the Access Matrix Model [12][6]. In this general model (figure 4) there exists a set of passive Objects which are the resources to be protected, and a set of active Users (or Subjects) who wish to access these objects. Each User, Object pair (U, O) is associated with an access right(s). An access right is a privilege that a user (U) has over an object (O). A user may access an object in a way specified by the access right(s) held by the pair (U, O).

U2

O2

O1

Read/ Write Read

O3

Objects

U1

Write

Users U3 U4

...

Un

Read/ Write

Write

Write Read/ Write

Read

Figure 4: The access matrix model

In most systems, the size of the matrix would be huge, as every object (row) and every user (column) would have to be mapped. In addition this matrix would include large amounts of wasted space if a number of objects were restricted to personal use. To combat this a number of more specific models were derived from the access matrix (denoted in figure 5) 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.

O1

U2

U3

U4

U4

O1 Read/

Read/ Write Read/ Write Write

Write

O3 Read/

Write

Access list for Object "O1"

Capability list for User "U4"

Figure 5 : Access and capability lists

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-

8

Smith, Rodden


user collaborative environment. Shen and Dewan [16] highlights the following problems with the above model : • It does not facilitate the use of roles or groups; individual users must be used. • It does not facilitate easy specification of complex 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 incorporates the notion of roles to group users. A role is used to group together a number of users, and it may define a user’s status. Roles are purely a shorthand for describing access and no implication is made between roles and the behaviour associated with users in that role. Unlike many models using a fixed set of permissions, such as Read, write, Edit, etc., our model facilitates an extendible matrix to specify permissions. The permission matrix is constructed from two extendible access lists, one for the user’s access to the object and another for the level of sharing. We use access lists over capabilities as each object must readily know each users access to itself (as it must present itself on demand), whereas a user is not directly concerned with their access to objets, merely their representations. 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. Methods

Use

Sharing

Usable or 'Pressable' Moveable Resizable Figure 6: A permission Matrix for a Button

9

Smith, Rodden


For each user, the permission matrix records if the user can invoke that method. A second column in the permission matrix states 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 6). We use flags as entries in the permission matrix because they are simple, flexible, semantically light, and extensible. No set of permissions are enforced by the access model, the semantics are defined behind each flag by the system implementing the access model. The value each flag may assume in our implementation of the model is one of four possible states. Each state denotes whether the access is granted or denied, and whether this setting may be altered by the end-user. The four states are represented by the letters {T, F, t, f}, as denoted in figure 7: Access granted Not end-user

Access denied

T

F

t

f

tailorable End-user tailorable Figure 7: Possible values each flag entry may assume

This effectively gives us two levels of specification. One where the application developer or privileged user may force fixed permissions of a SOLO 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. 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 8. 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.

10

Smith, Rodden


Figure 8: Permissions of “The button” for three users

From figure 8, 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. If the above figure were access permissions for a text field, where Tom’s and Andy’s text is shared, any changes Tom makes to the text are immediately updated on Andy’s display too. With our current implementation, if Jon now wishes to share his text field with the others by selecting the “usable-shared” button, then his text field will be overwritten by the text held within the shared fields. Thus the state information associated with each shared interface object is shared. On merging, shared information has precedence over the private copies of the state associated with individual views. Our architecture allows a number of multi-user applications running simultaneously in an environment containing a number of servers. Because of this we have chosen a client-server model for our access control system, where an application will contain an access client within the Display Manager. A client invokes a request to a server by 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 SOLO, 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 The permissions, visible, usable, moveable and resizeable are sufficient for the majority of the SOLOs defined so far. As further SOLOs may be added, the four permissions may not be sufficient to cover all the features offered by the new SOLO.

11

Smith, Rodden


The addition of new permissions for new SOLOs is a simple matter of creating additional permission flags for that SOLO. 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. Therefore 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. PERMISSION RESOLUTION A user’s permissions for a particular interface object will normally be derived from one or more roles. So a particular user’s individual permissions may be affected by any of the roles of which they are a member of. To allow these permissions to be consistently resolved, specifications of an interface object’s permissions are ordered in a list. The top most role in the list has priority over those proceeding. Two simple rules are used to derive a user’s permissions from the list (moving downwards), these rules are: 1. The first occurrence of a 'T' or 'F' within a column remains, overriding any current 't' or 'f' value. 2. An unspecified field (i.e. one that does not contain a 'T' or an 'F' after the list is traversed) assumes the users’ own preference (which will be a 't' or 'f’). If the user is not present within the list, the first occurrence of 't' or 'f' for that field is used. So for example, some of the possible permissions (for simplicity, we have not included the sharable aspect) for a SOLO may be: Usable students SEgroup

Moveable Resizeable

T F

t F

f t

Figure 9: A SOLO’s access specification for two roles

If a user is a member of both the above roles, their access permission can be derived using the two rules above. In the usable column the first entry 'T' remains the permission for that user (using rule 1). The same rule applies for the second field,

12

Smith, Rodden


where the 'F' overrides the 't'. The second rule applies for the third field as no 'T' or 'F' has been selected, which returns the first occurrence of any value, which in this case is 'f' from the students role. So then the returned permission for such a user will be:

T

F

f

Figure 10: Resulting permission for member of both roles in figure 9

User interface permission inheritance So far, we have described the derivation of a user’s permissions for one user interface object. Here all objects are isolated from each other, and any common behaviours must be respecified for each one. To simplify the process of SOLO permission specification, we also provide a means for permissions of a parent SOLO to alter those specified in the child. For example, this may permit one container object to prevent all its children from being moved, without the user having to manually alter each SOLOs permissions. We use one permission rule for each container type SOLO to dictate the level of influence a parent has over its children. The permissions Childp of the child SOLO may be derived from those of Parentp in a way defined by the permission rule R, held by the parent SOLO. So far we have defined two permission rules (R), and in accordance with the rest of the access model, these rules may be extendible. We define R as one of:

Rule None

Effect Childp remains as specified, regardless of those specified in Parentp Override Childp inherits exactly the permissions held within Parentp, regardless of its original specification Figure 11 : Two permission inheritance rules

For example, consider a container which may not move or be resized. We could now give that container an Override permission rule. This would not permit any of its children to resize or move within it, whatever their own permissions, but makes no difference to the usable (or any other) fields. In this way we have a permission filter. To derive a child SOLO’s permissions, we not only consult its parent SOLO’s permissions, but also its parent’s parent, and so on. This allows us to specify restrictions over a user's access to objects from a higher level of abstraction in the interface. For example, giving a container an 'F' value in the movable permission and using the override rule, any children of the container cannot be moved. Furthermore, if one child was also a container, none of its children may be moved. If the case was such that the children of the second container needed to be moved, we could use the

13

Smith, Rodden


Override rule in the second container to grant that permission. Thus containers with override rules nearest to a SOLO in the interface hierarchy have priority over those higher up. It is also possible to associate one SOLO’s entire access permissions with an other. That is, one object’s access specification may be shared among other objects. For example, in figure 12, the “quit button” of an application has a defined access specification, which is also used by the “open button”. The link (or alias) to another object’s permissions is treated as a special role, and as such, may be included into the other button’s access permissions. Access Specifications

Resulting permissions for the Open Button

Quit Button

Open Button

Figure 12: Linking access permissions

In the simplest case the “open button’s” access specification may only have the link to the quit button’s access specification. Linking in this form allows for complex access specifications to be shared between SOLOs. In addition, as in figure 12, a SOLO may include another’s specification amongst its own specifications, thus refining those included. An example of the 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 SOLO’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 13: Roles within an academic department

Now consider as an example a scenario in an academic environment, containing staff and students. We group the users as in figure 13 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

14

Smith, Rodden


simple application has been constructed that allows the placement of shared “notes” onto a shared board (figure 14).

Figure 14: Example of the multi-note application

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 SOLO’s. A base, a title, a text body and a close button which destroys the note. The hierarchy is denoted in figure 15. Base

Close

Title

Text body Close

SOLO Hierarchy of a note

Example image of a note

Figure 15: Relationship between SOLO 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 16.

15

Smith, Rodden


Figure 16: 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 17. 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 17: Permissions for Doug’s title field

Deeper interaction and cooperative semantics So far we have described our model of a shared interface architecture. In this we have a shared interface, and an access driven mechanism to derive individual interfaces for each user. Any interactions a user makes with their interface are received by the application. Took [23] describes this as deep interaction. He suggests that a user interface infrastructure should support surface and deep interaction. Surface interaction occurs when a users interactions with the interface do not directly involve the application. For example, moving a button need not invoke its functionality.

16

Smith, Rodden


SOL provides both surface and deep interaction, figure 18. Deep interaction occurs when a user clicks a button, selects a menu, or whenever an event 1 in which the application is interested occurs. Surface interaction is provided by modifying other users displays when shared methods of SOLOs are invoked. For example, if a number of people share the movement method of a button, when one user moves it around the screen, its position is updated on the other user’s displays. During this simple operation, the underlying application need not be invoked. User User UserUser Surface interaction

Shared Interface Layer Deep interaction

Application Figure 18 : Surface and deep interaction

Deep interactions thus far are collaboration transparent, that is all users’ interactions (button clicks or key presses) are indistinguishable by the application. We are currently investigating the specification of collaboration semantics within the shared interface layer. Such a feature should be modifiable at run-time (as is our access mechanism) and provide a means of telling the application in what context the deep interaction took place. This context may be derived from some status the user holds. The application may then choose to use or ignore this context. To store a users “status” we have included a simple database into our architecture, called the “User Profile”. A user profile holds some resource information for each user. The semantics of the resources are application dependant. An application may read, alter, add and remove a user’s resources. These calls are invoked by the server on the application’s behalf, via a remote procedure call. An application may store information such as the name of the activity a user is in (if the application embodies some kind of activity model). This information may then be used to specify the collaborative context. A common feature within collaborative systems is a voting tool. The vote counting procedure should be a surface interaction, then a deep interaction invoked to tell the application the outcome of the vote. We are working to extend our SOLO objects to include tailorable such collaborative semantics. 1 User interface events such as mouse button clicks and key presses.

17

Smith, Rodden


THE ARCHITECTURE We have realised our model using the X-Windowing system [17], the OSF Motif Widget set, C++ and ISIS operating on a UNIX platform. Our architecture, SOL, consists of a number of key elements. The server 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 system, a more likely scenario is one of multiple users and multiple applications. The diagram however, shows all the objects in SOL, each of which provides different services. UserPanel

Application Interface

A user's screen

SOL Server Display Manager

Application Figure 19: The SOL Architecture

A user panel is the user’s interface to the server. It shows the number of open sessions and who is using them, together with a list of applications from which new sessions may be spawned. The existence of the user panel denotes that the user is registered with the server. The server itself manages and coordinates any number of users who may by partaking in zero or more sessions2 at any one time. It requests inclusion and removal of users from individual sessions on their behalf. The server contains many mechanisms including the access server and user panel server. 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 system supports multi-user interaction throughout these phases. Users register with SOL via a small invocation application. The server receives the message from this application, which includes the display they are using and their user name. Then a user panel is constructed for them by the server. The user panel is a multi-user interface constructed from SOLOs, and as such the buttons and text fields may be constrained or shared at will. For example, we may allow staff to create and join sessions, but restrict students to only joining sessions.

2 We understand a session to be an active application

18

Smith, Rodden


If a user creates a new session by clicking on one of the available applications, the server spawns the application, then requests an interface of the application for that user. If a user wishes to join an existing session then the server simply requests an interface for the user from that application. UserPanel

Application Interface

A user's screen

SOL Server

Appl icatio n Cre ation Perm issio n Re solut ion

User Interface Construction Display Manager

Application Database containing access specifications, role entries, and user profiles Figure 20: Application creation and permission resolution

On joining a session (a new or existing one), each user’s interface is constructed by the sessions display manager, see figure 20. 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. SUMMARY AND CONCLUSIONS 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 traditional access models fall short of our requirements for an access control model within our collaborative environment. Our access model is specifically designed for multi-user collaboration. The permission model used enforces limited restrictions on context of the user and is extendible for a range of interface objects. In the developed environment the 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. User interface objects allow permitted/authorised users to dynamically alter their user interfaces with respect to appearance and level of sharing. The developed environment offers the ability to provide both collaboration aware user interfaces and collaboration transparent user interfaces within a common framework. The use of the sharing field in the permission matrix allows developers and user to directly manage the level of collaboration awareness at a given time. As a

19

Smith, Rodden


consequence some users can collaboratively work together while others interact with the application in a purely collaboration transparent manner. We have developed a number of cooperative applications using the SOL environment. These include a simple brainstorming generator tool, a minute taking facility and a network administration tool. In addition, we have also used the environment to produce cooperative aware multi-user tools from existing single user applications by amending the source code to use our interface objects rather than the original interface widgets. The SOL environment represents our first step at outlining a set of generally useful mechanisms for cooperative user interfaces. Future work also includes the investigation into the role policies to manage interaction within our environment. We will also investigate the support of “deeper interaction”, where an interface decides which 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. Moreover if we scale up our domain from local area, to wider area networks, the delays incurred may make the environment unusable. Semantic feedback may be sluggish, and we would desire our environment to support more fine grain distribution, including a replicated federated system daemon. The development of an appropriate architecture for cooperative systems represents a significant long term goal for our work. ACKNOWLEDGEMENTS This work was partially funded by the COMIC project (ESPRIT project no 6225), the Science and Engineering Research Council and IBM Laboratories UK. Our thanks are due to our partners in the project, and our colleagues within the department at Lancaster. REFERENCES [1] Bentley, R., Rodden, T., Sawyer, P., Sommerville, I. "An architecture for tailoring cooperative multi-user displays." CSCW '92, Toronto, Canada, ACM Press, [2] 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. [3] 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 1014, Editor: C. Unger and J. A. Larson, 20

Smith, Rodden

[4] [5]

[6] [7] [8] [9]

[10] [11]

[12] [13]

[14]

[15]

[16] [17] [18]

[19]


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 0-7923-1439-5. 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 Patterson, JF. “Comparing the Programming Demands of Single-User and Multi-User Applications”. Proc. Symposium on User Interface Software and Technology, Hilton Head, South Carolina, November 1991. Pages: 87-94. 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: 147-167. Tatar, D.G., Foster, G., Bobrow, D.G. "Design for conversation: lessons from cognoter." Int. J. Man-Machine Studies (1991) 34 Pages: 185-209.

21

Smith, Rodden


[20] Lee, J.J. (1990): "Xsketch: a multi-user sketching tool for X11." Proceedings of the Conference on Office Information Systems April 1990, 1990, Acm press, Pages 169-173. [21] Greenberg, S., Bohnet, R. “GroupSketch: A multi-user sketchpad for geographically-distributed small groups”. Proc. Graphics Interface 1991. Pages: 207-215 [22] Dewan, P., Choudhary, R. “Flexible User Interface Coupling in Collaborative Systems”. Proc. of the ACM CHI ‘91 Conf. April 1991. Pages 41-49 [23] Took, R. “Surface interaction: A paradigm and model for separating application and interface”. CHI 1990 Proceedings, Pages: 35-42.

22