Draft Only - Do Not Distribute 1

The Zone/View/Workspace Model

Gregor McEwan, Tim Mansfield, Ted Phelps, Simon Kaplan
Cooperative Research Centre for Distributed Systems Technology,
University of Queensland,
Australia
tim.mansfield@dstc.edu.au
October 12, 1999

Abstract As we discuss in detail in Section 2 this model

moves away from the “group-in-a-room” metaphor
The Orbit prototype collaboration system [7] is unusual which characterised several well-known groupware re-
in that it presents communication and collaboration to search prototypes (including the wOrlds prototype, Or-
the user via a layered, configurable interface abstraction bit’s predecessor) and now various commercial sys-
called the zone/view/workspace model. This abstrac- tems.
tion has been mentioned in earlier reports on Orbit, but Our contention in this paper is that the
never fully explained. We believe that the abstraction zone/view/workspace model provides a better way
is an interesting and novel way to present collaboration to integrate personal and group organisation of work
and communication to users. This paper presents the than the “group-in-a-room” metaphor.
abstraction in detail with several examples of its use. The system has been documented in several publica-
Our contention is that the zone/view/workspace model tions and is currently being trialled by a user community
provides a better way to integrate personal and group who use it to coordinate work on document-focussed
organisation of work than the more standard “group-in- projects. We hope to report on the usability outcomes
a-room” metaphor. of these trials in future publications.
This paper describes the zone/view/workspace model
in depth. Section 2 details our core argument. Section 3
1 Introduction describes the abstract version of the model. Section 4
describes the navigator tool that allows users to config-
ure workspaces. Section 5 outlines an initial prototype
Orbit is a collaboration tool which attempts to support
of the model which was based on attempts to “enhance”
users who have to collaborate within multiple groups
a desktop-style workspace. Section 6 describes an al-
around documents. It provides facilities for storing,
ternative tree-structured workspace. Section 7 outlines
managing and organising documents which belong to a
future directions for the work and Section 8 summarises
group alongside the means to communicate with other
the paper.
members of the group.
Orbit implements a flexible user interface
model which allows users to rapidly reconfigure 2 Groups, Tasks and the Organi-
the information shown in their workspace. This
zone/view/workspace model is based on building sation of Work
workspace configurations from user-created views
of group information. The consequence is that the Collaboration systems that provide persistent access to
documents and communication facilities an individual a collection of objects, such as documents, pictures,
uses can be changed very quickly. chat sessions and so on, need some way to organise this
collection of objects to make it easy for collaborators


Submitted to AUIC 2000 to find and access artifacts and communication facili-
Draft Only - Do Not Distribute 2

ties. Many systems, quite rationally, structure their or- on Henderson and Card’s study [1] and our own obser-
ganisation based on the groups which own or control vations [4] it is clear that such a design does not support
the artifacts. This decision is presumably based on the some kinds of task behaviour.
common-sense observation that most collaboration hap- So, we are left with a dilemma: how do we design
pens within groups. In previous papers [4, 7] we coined a system which accounts for both the social or group-
the term locale to refer to the notion of a physical or based organisation of artifacts and facilities and the in-
virtual place for a group to cluster its artifacts and fa- dividual, task-based organisation of the user’s personal
cilities. We can therefore think of places or spaces pro- workspace? The approach we have taken in Orbit and
vided in a software collaboration system to contain a that we report in this paper is simply to keep the two
collection of objects as a kind of virtual locale. types of organisation distinct.
A key design issue is then how to present these virtual Orbit provides the user with distinct access to a kind
locales to the user. A common solution used by many of locale (which we call group zones) and a Rooms-like
research prototypes which use locales as a means of or- way to organise the workspace (via a mechanism called
ganising objects (such as CVW [8], CBE [5], MAS-
workspace configurations). The next section explains
SIVE [2] and wOrlds [6]), and an increasing number of the user interface model that allows the user to use these
commercial systems is to present the locale as a room. abstractions to access artifacts and facilities.
This metaphor of a “group-in-a-room” appeals to com-
monsense notions like office, club-house, home and so
on. Logical predecessors can be found in text-based
collaborative environments - so-called MUDs or MOOs 3 Zone/View/Workspace Abstract
[3].
The notion of structuring the visible workspace of the Model
computer as a kind of room also owes a debt to the influ-
ential Rooms system [1] which is the best known early The zone/view/workspace model is composed of three
attempt to provide multiple virtual workspaces which core concepts: group zones, views on the group zones
can be displayed on a single screen. This design was and a workspace composed of the views. The following
subsequently copied widely, notably by various virtual discussion describes these three concepts in an abstract,
window managers in the Unix/X11 environment (such implementation-independent way.
as tvtwm, fvwm and WindowMaker).
One of the key ideas in Rooms was to present clusters
of artifacts and tools related to a task:
3.1 Group Zones
The design of the Rooms system is based on
the notion that, by giving the user an interface Group zones are a software abstraction which provides
mechanism for letting the system know he or she a virtual locale to support the work of a group. Each
is switching tasks, it can anticipate the set of zone maintains a list of users who are the members of
tools/windows the user will reference and thus the group.
preload them together in a tiny fraction of the time Users whose work centres on documents require ac-
the user would have required to open, close, and cess to a shared repository for documents of various
move windows or expand and shrink icons. A fur- types and a set of communication facilities that allow
ther benefit is that the set of windows preloaded on various kinds of communication from simple, textual
the screen will cue the user and help reestablish chat to video-conferencing. Accordingly, each group
the mental context for the task. – [1] p221. zone gives its members acces to a collection of arti-
The problem with equating the concepts of locale facts (such as documents, links to web pages or folders)
(used to organise artifacts by the groups which own and communication facilities (such as a text chat tool or
them) and room (used to organise the artifacts by the videoconferencing). This collection is called the zone’s
individual’s tasks) is that groups and tasks, while re- contents.
lated, are not identical. An individual’s task may use Some of these types of content are displayed by Or-
artifacts and facilities from multiple groups and, con- bit, but most are displayed using external tools (such as
versely, groups may be the site for multiple tasks. Based web browsers, editors or video conferencing tools)
Draft Only - Do Not Distribute
3.2 Views on Group zones
Views are designed to allow different perspectives onto
the contents of a group zone. The model defines views
in terms of two elements (adapted from [7]):
3
been selected for each zone. Each user’s workspace
shows all of their views of the zones that they belong to.
The workspace gives a personalised look at the owner’s
work focus across all of the zones that they belong to.

 
 
projection: the subset of the contents which are visi-      

   
!#"$ %&'


ble,

geometry: the position and size of the visible content,

Both of these elements may be implemented in var- (*) +$, -$.0/21$) / 9 ) 1$/:1$6$- ; ; ;$< =>/2-
ious ways, specifically, geometry will mean different
things depending on how artifacts and communication
facilities are displayed. We will described this in more
detail in Sections 5 and 6 in reference to the specific
workspaces. 3 , 4- 5$, 6$7$8 ? 1>@BAC, 1$@
In addition to these two core elements, views are also
defined as either shared or personal.
Shared views are accessible by all members of the
group zone and allow every member of the group to
see the contents of the zone with the same projection ? , 7>1$D E /*FCG$H I>H>1$J G$=$D - K
and geometry. Members with the same shared view se-
lected can therefore see the same documents and links
and have access to the same communication facilities. Figure 1: A diagram of how the zones, views and
The purpose of views is to allow the groups to tailor workspace interact.
the way that they look at the zone. With the use of view
definitions groups can define what they see in a way Figure 1 shows a sketch of what the workspace dis-
plays. A mythical user, Tim, belongs to the zones O R -
that best supports their current task. Shared views give
a common reference to the group members and provide BIT U SERS , T IM THINGY and N IGEL’ S PAD . The
artifacts of these three zones are filtered through the
a basis for the group to collaborate. Views act as a filter
views that Tim has selected for each of the zones,
on the artifacts in each of the zones which focuses on a
particular aspect of the group activities. “ PRESENT... JUST ”, “N EW V IEW ” and “¡ DEFAULT ¿”,
A personal view is only accessible to the user who respectively. Tim’s workspace displays the artifacts
creates it. Personal views support the fact that each from all of the views that he currently has selected.
member of a group may have a different role to fill A user can save a set of views as a workspace con-
within that group and therefore different tasks to per-figuration which provides the means for supporting the
form. individual’s need to organise their workspace to support
Users have a number of views available to them for their personal tasks.
In summary, the model consists of group zones each
each of their zones. The list that they can select from in-
of which is a virtual locale to support the work of a
cludes all of the shared views that have been defined by
the group as well as any personal views that they have group, views of those zones, and the workspace which
defined themselves. The model does not prescribe the displays the current views of each zone to support the
purpose of these views: they can be created to support individual’s current task.
different tasks or roles or to support different levels ofThe zone/view/workspace model separates the social
involvement in a zone, for example. and group aspects of work organisation from the in-
dividual task-based aspects. Individuals can configure
their workspace to show artifacts that support the task
3.3 The Workspace
irrespective of group boundaries, while still maintain-
The workspace displays all of the group zones that the ing the group structure (via the zones). This design ac-
user belongs to, filtered through the views that have knowledges and supports what we believe (based on our
Draft Only - Do Not Distribute
own observation [4]) to be a key feature of work prac-
tices, that tasks occur not just within groups but also
across groups.
4 The Orbit Navigator
The following two sections deal with the two proto-
type workspaces we have implemented so far, the desk-
top workspace (Section 5) and the tree workspace (Sec-
tion 6). This section deals with the tool which config-
ures the views in both workspaces: the Orbit navigator.
Figure 2 shows a user’s desktop with Orbit running. The
navigator window is on the left.
The primary function of the navigator is to allow the
user to configure the workspace, it also serves a central
place to gather functions and information related to Or-
bit so that, regardless of whether they are displayed in a
given workspace, they can still be accessed by the user.
The navigator shows a panel for each zone. These
panels are also endowed with a colour chip so the user
can easily identify the zone. These colours are also used
in the workspaces as we will see in the following sec-
tions.
The panels also contain a view pulldown menu for
changing the current view and a pop-up menu for less
common manipulations such as changing the member-
ship of the zone or creating and editing views or ar-
tifacts. The names of the current views are displayed
on the view pulldown menus (for example, the zone
AUIC-2000 has the current view “ DOCS AND FACE ”).
This view menu lists both shared and personal views,
distinguishing between them by colour.
The panel also contains a sub-panel in which tiny im-
ages of users can be shown. This is intended to be an
awareness mechanism for indicating who is currently
active in the zone. Whether this sub-panel is shown or
not is another of the facilities that can be selected when
defining a view.
The pulldown menu at the bottom of the tool lets the
user select (or type in) a string which describes their
current activity. This string is shown in a small popup
window (or “tooltip”) when the mouse is held over a
user’s image in the face sub-panel.
Views are created by opening a view editor from the
zone panel, turning on or off the audio, video and chat
window and selecting whichever artifacts are desired
and then arranging them in the workspace. The view
can then be saved with a name and defined to be either
personal or shared.
4
Workspace configurations are created by selecting
the desired views and then selecting the “save config-
uration” function from the navigator’s menu bar which
allows the configuration to be named. The name of the
current configuration is shown in the navigator’s title
bar. The navigator in figure 2 has the configuration
“PAPER ” currently loaded.
Both workspaces share this navigator tool, a chat tool
and audio- and video-conferencing tools.
5 The Desktop Workspace
5.1 History and Motivation
The desktop workspace was the first user interface we
built for Orbit and was designed to address limitations
we perceived in its predecessor prototype, wOrlds [6].
The wOrlds prototype is essentially an audio/video-
enhanced MUD. It consists of a collection of rooms
among which the users of the system may move. When
a user is in a particular room, she may access the arti-
facts in that room and see who else is around. Addition-
ally she automatically joins the audio and video confer-
ences for that room so that she may communicate with
the other users there.
The wOrlds prototype was first attempt to build a sys-
tem with virtual locales (the rooms in wOrlds were even
called locales), so each of these rooms was intended to
support a group. We had built an implementation of the
“group-in-a-room” metaphor.
As we discussed in Section 2 we came to feel that
the “group-in-a-room” metaphor, although superficially
intuitive, fails to support the user’s actual work in part
because it was simply too restrictive, in part because a
person can only be in one room at time. We wanted to
remove the walls for our rooms, so we started calling
them “zones” and we set about trying to understand the
implications of an open-plan MUD. From this grew the
ideas of zone membership and views discussed earlier
in this paper.
We wanted our users to feel comfortable with the Or-
bit user interface so we chose to base it on something
familiar: the ubiquitous desktop made famous in Ap-
ple’s MacOS1 operating system. Our initial plan was to
present artifacts from various zones in the user’s desk-
top. These, along with audio and video tools and a con-
trol for shifting between different views of these fur-
1 Apple and MacOS are trademarks of Apple Computer Inc.
Draft Only - Do Not Distribute 5

Figure 2: A screenshot showing the navigator, the tree workspace, the chat tool and a video window from the
S OCIAL P ORTAL zone.

nishings would hopefully allow us to test if zones and “desktop workspace,” described in detail in the rest of
views were good abstractions. this section and shown in Figure 3.
At this point we ran into some problems. Although it
Because the colour chips are difficult to discern in
is conceptually quite easy to add Orbit’s artifacts to the
a monchrome image, we have added labelled, dotted
user’s existing desktop (in recent versions of Windows2 ,
curves around groups of documents in the same zone in
for instance), it turned out to be logistically quite chal-
figure 3. These do not appear in the actual workspace.
lenging. In addition, our shift away from rooms and
In fact the absence of any explicit representation of the
boundaries towards zones required that we be able to
concept of “zone” distinguishes the desktop workspace.
display artifacts from multiple zones simultaneously on
the desktop. This led us to the twin difficulties of influ-
encing the artifact layout of the existing desktop system
(users often seem to prefer to cluster the artifacts from a
given zone) and identification (knowing which artifacts
5.2 Views
belong to which zones if they aren’t spatially clustered
is important).
As a first cut, we chose the most naı̈ve solutions to According to our abstract model, a view consists of the
these problems. Rather than trying to integrate with the projection of the zone’s contents and the geometry for
user’s existing desktop, we chose to simulate it within each element. In the desktop workspace, the view’s pro-
a window. We stored artifact layout information as part jection determines which artifacts are displayed as icons
of a view, thereby transferring this problem to the users on the workspace, its geometry the position of those ob-
(new artifacts are always placed in the upper left-hand jects in the two-dimensional space of the desktop.
corner of the desktop). Finally, we attached a colour The artifacts displayed in the workspace can be
chip to the left edge of an artifact’s title to indicate dragged around by the user to find an appropriate lay-
which zone it belongs to. These decisions led us to the out for that view. When the view is saved that layout
2 Windows is a trademark of Microsoft Corporation becomes the geometry for the view.
Draft Only - Do Not Distribute 6

not rooms and we felt that a separate window for each

] P ^_Q `P aSbSc zone failed to make this distinction.
Other more interesting solutions to the scaling issue
are possible. To help address the problem of colours
for large numbers of zones, we considered allowing the
W RX YZ [V\>\V\
members of a zone to choose from a palette of looks
for their zone, so that each zone might have differ-
ent artifact icons, different foreground and background
colours, and possibly textures and so on.
We briefly considered addressing the layout prob-
lem by implementing a layout algorithm that treated
each user-defined view layout as an element that the
workspace was responsible for placing at some posi-
tion within the desktop. The geometry element of the
view would then record the position of each artifact in
LNM OP QSRT>UVM T the view relative to the other artifacts in the view.
We did not, in fact, pursue either of these avenues
because the order of effort involved seemed to out-
weigh the advantages of maintaining a resemblance to
Figure 3: The desktop workspace the classic desktop metaphor. This leads us to the sec-
ond weakness of this design which is more subtle. By
taking the familiar desktop and changing it, we had cre-
5.3 Workspace
ated a rather frustrating environment that changes the
The desktop (or rather, desktop-like window) clearly rules that users have previously learned. We have con-
embodies the workspace concept. In this case, the views ducted several informal, internal trials of this prototype
of each zone are all shown in the same workspace. Arti- workspace and the resulting confusion is obvious and
facts from different zones may be arranged so that they unambiguous. Our desktop may superficially resemble
are clustered together in the workspace because the po- the MacOS or Windows 95 desktop, but it doesn’t be-
sition of each artifact is recorded as position relative to have much like it.
the origin point of the desktop.

5.4 Weaknesses Of The Desktop Design 6 The Tree Workspace

The chief weakness of this design is that it doesn’t scale
well to many zones. Using colour chips to indicate the
zones to which artifacts belong is clearly fraught with
peril: how many different shades of red can a person
reliably distinguish? What about colour-blind people?
Encoding the placement of icons as part of the view
fares no better. What if views from two different zones
place their icons in the same area? How many zones
can be usefully displayed on a single desktop simulta-
neously?
Clearly, one solution to this problem is to relinquish
the desktop concept and use a separate window to dis-
play the icons of each zone. In this situation, colours
are no longer required and the layout problem simply
disappears. We initially were unable to use this solu-
tion due to drag-and-drop limitations of our inital GUI
tool kit. We also wanted to emphasize that zones were
The tree workspace was built to overcome some of the
limitations of the desktop style workspace by using a
simple, hierarchical layout (familiar from graphical file
browsers) rather than the 2-dimensional surface of the
desktop. This section begins by explaining how the tree
display operates in relation to group zones, artifacts,
and views, and how it brings all these things together.
We then look at how this workspace design overcomes
some of the weaknesses of the previous desktop style
workspace.
6.1 Representing Zones
The workspace representation of the group zone takes
the form of a node in the tree, and displays the artifacts
of the zone. The tree workspace differs from the desk-
top workspace by the functions it provides as well as
Draft Only - Do Not Distribute 7

the structure. A number of zone-related functions (such save the position of an artifact in the list of siblings in
as creating new documents or folders) have been dupli- the tree and perhaps the level of indent and the size of
cated in the workspace because the group zones are now the artifact icon or the text label.
explicitly represented in the workspace.
Associated with each group zone is a colour chip that
6.3 Workspace
is shown in in both representations of the group zone.
The colour chip provides a visual link between the zone As can be seen in the figure 4, the workspace shows
representations in the navigator window and workspace all of the group zones. This implements the concept in
window. Note that because the artifacts are grouped into the abstract model of the workspace of views. Each of
zones by the tree layout, the colour chip no longer needs the zones shown is filtered through the selected view
to be attached to every artifact in the workspace. to determine which of the artifacts are displayed. The
The structure of the level of the tree that displays the group zone nodes re-
tree reflects the folder mains constant, showing all the zones of which the user
containment hierarchy is a member. The next level of the tree is the contents
in a zone. The artifacts of those zones and this level is composed by the user’s
that belong directly to currently selected views.
a group zone are dis-
played as children of the
6.4 Addressing the problems of the desk-
group zone node in the
workspace. Artifacts top
that are placed in folders The tree workspace was built to overcome two prob-
are children nodes of lems of the desktop workspace, both of which were in-
the folder nodes and so troduced in Section 5. Its design addresses the prob-
on. lems of scalability with the colour chips and positioning
The artifacts within problems across multiple overlapping shared views.
a group zone are listed The tree workspace removes the requirement for hav-
underneath that group ing unique colours for each zone for the colour chips.
zone node and indented Artifacts are now associated with their group zones by
slightly. Artifacts that position rather than by colour. The colour chips exist
are within folders show on the tree workspace only on the group zone nodes,
Figure 4: The Tree their membership in that no longer on the artifacts. They are there to give a vi-
Workspace folder in the same way. sual link back to the corresponding group zone on the
The screenshot of the navigator window. As it is only an aid and not the only
Tree Workspace in figure 4 shows an example of the link between the two representations, the colours are no
containment relationship. The size of the artifacts does longer required to be unique.
not vary in this implementation. The problem of having to position artifacts uniquely
across many group zones is no longer relevant in the
6.2 Views tree workspace. The problem arose because artifacts
from different zones were able to be placed anywhere
The abstract zone/view/workspace model (Section 3) in a shared desktop space. In the tree workspace each
defines views in terms of projection and geometry. In zone effectively has its own space to place artifacts.
our implementation, the tree workspace only requires
the projection element.
Projection, or visibility, determines the set of artifacts 7 Future Work
that form the immediate children of the group zone node
in the tree. The most important item of work which is ongo-
The geometry element is not used by the tree ing at the time of writing is subjecting the prototype
workspace. All nodes are automatically laid out in the workspaces to user evaluation as a way of getting feed-
tree, the user has no control over the ordering or place- back on the viability of the model. We are installing Or-
ment of the nodes. Geometry could however be used to bit (with both workspaces as available as alternatives)
Draft Only - Do Not Distribute 8

for a volunteer user community whose work centres on Acknowledgements

the discussion and preparation of documents. Our ini-
tial deployment will involve a brief period of training The authors would like to thank the other developers
and a workshop to elicit aspects of the group’s work that of the various versions of Orbit: David Arnold, Mark
Orbit might be used to support. We intend to carry out Fitzpatrick, Michael Henderson, Andrew Loch, Blaize
an informal evaluation over a period of several weeks, Rhodes, Rik Taylor without whom the work reported in
based on user reports and informal interviews. We are this paper would have been impossible. We would also
particularly interested in whether use persists after the like to thank Geraldine Fitzpatrick and Austin Hender-
initial period and if not, what deterred ongoing use. son for valuable discussions and Saul Greenberg for his
comments on this paper.
We are also interested in extending the abstract model
to allow views to be composed from other views, so The work reported in this paper has been funded
that several views might display a common set of docu- in part by the Co-operative Research Centre Program
ments, for instance, or a common set of communication through the Department of Industry, Science & Re-
facilities. sources of the Commonwealth Government of Aus-
tralia.
Another planned extension is to apply the This work has also been supported in part by the
zone/view/workspace model to the layout of web United States Defence Advanced Research Proj-ects
pages, allowing us to make a web-based workspace. Agency under grants F30602-96-2-0264 and F30603-
94-C-0161 (both administered by the US Air Force
through Rome Laboratories). The views and conclu-
sions contained in this document are those of the au-
8 Summary thors and should not be interpreted as representing the
official policies, expressed or implied, of the Defence
Advanced Projects Research Agency or the U.S. Gov-
We contend that the zone/view/workspace model pro- ernment.
vides a better way to integrate personal and group
organisation of work than the “group-in-a-room”
metaphor. References
We argued the need for a model which which ac-
counts for the need to both organise artifacts and com- [1] Stuart K Card Austin Henderson. Rooms: The
munication facilities according to the groups to which use of multiple virtual workspaces to reduce space
they belong and organise the workspace according to contention in a window-based graphical user inter-
the user’s personal tasks and activities. face. ACM Transactions on Graphics, 5(3):211–
243, July 1986.
We outlined the zone/view/workspace model which
we believe does just that by providing the user distinct [2] Steve Benford, Adrian Bullock, Neil Cook, Paul
access to both kinds of functions. Harvey, Rob Ingram, and Ok-Ki Lee. From rooms
We presented two different implementations of the to cyberspace: models of interaction in large vir-
zone/view/workspace model which we have prototyped tual computer spaces. Interacting with Computers,
in the Orbit collaboration system, namely the desktop 5(2):217–237, 1993.
workspace and the tree workspace. These prototypes
[3] Pavel Curtis and Davis A. Nichols. MUDs grow up:
have been informally evaluated in internal trials and are
Social virtual reality in the real world. In Proceed-
currently being deployed to a volunteer user community
ings of the 1994 IEEE Computer Conference, pages
for further evaluation.
193–200, January 1994.
While we are not convinced that the specific imple-
mentations we have prototyped are the best ways to [4] Geraldine Fitzpatrick, Tim Mansfield, and Simon
present collaborative environments, early evidence sug- Kaplan. Locales framework: Exploring founda-
gests that the abstract model is a better representation tions for collaboration support. In John Grundy
of how groups and individuals commonly organise their and Mark Apperley, editors, Proceedings Sixth Aus-
work than the “group-in-a-room” metaphor. tralian Conference on Computer-Human Interac-
Draft Only - Do Not Distribute 9

tion, pages 34–41. IEEE Computer Society Press,

1996.
[5] Trent Jaeger Jang Ho Lee, Atul Prakash and
Gwobaw Wu. Supporting multi-user, multi-applet
workspaces in cbe. In Mark S Ackerman, editor,
Proceedings of the ACM 1996 Conference on Com-
puter Supported Cooperative Work, pages 344–
353. ACM Press, New York, November 1996.
[6] Simon M. Kaplan, Geraldine Fitzpatrick, Tim
Mansfield, and William J. Tolone. MUDdling
through. In Jay F. Nunamaker and Ralph H.
Sprague, editors, Proceedings Thirtieth Annual
Hawaii International Conference on System Sci-
ences (HICSS30), volume II, pages 539–548, Los
Alamitos, CA, 1997. IEEE Computer Society
Press.
[7] Tim Mansfield, Simon Kaplan, Geraldine Fitz-
patrick, Ted Phelps, Mark Fitzpatrick, and Richard
Taylor. Toward locales: Supporting collaboration
with Orbit. Journal of Information and Software
Technology, 41:367–382, 1999.
[8] Lucy M Deus Peter J Spellman, Jane N Mosier and
Jay A Carlson. Collaborative virtual workspace. In
Wolfgang Prinz Stephen C Hayne, editor, Proceed-
ings of the International ACM SIGGROUP Con-
ference on Supporting Group Work (GROUP’97),
pages 197–203. ACM Press, New York, November
1997.