7
In addition to the inherent research interest that synchronous computer-supported work
has (as the most “revolutionary” way to apply technology to the problem), the prevalence of
toolkits for synchronous work reflects the technical difficulty of supporting real-time inter-
action (and the consequent attractiveness of the problem to researchers). The most popular
model for synchronous interaction (the WYSIWIS or “What You See is What I See” paradigm)
makes heavy performance and consistency demands. Even toolkits like Suite, which allow
less tightly coupled interaction styles, are dominated by the mechanisms needed to support
synchronous, consistent interaction. That the performance implications of these approaches
are so different is one obvious technical reason that this split between systems has persisted
for so long. More fundamentally, computer implementations supporting asynchronous work
differ radically from implementations supporting synchronous work, because, in order to
guarantee consistency, asynchronous systems must generally accommodate the possibility of
inconsistencies arising during off-line work, or impose a work style involving the explicit
management of access via locking or rollback. While locking and rollback can still create
anomalies in the user interface of synchronous applications (Greenberg and Marwood 1994),
these mechanisms have been applied in the design of synchronous applications in order to
guarantee consistency, and reduce the impact of inconsistency.
However, recent research has clarified what might seem to be an obvious point about the
usefulness of dividing work into separate classes of synchronous and asynchronous (Dourish
1995; Dourish 1996). While current applications are often oriented to one or the other of
these modes of work, projects themselves are not split this way in actual work situations.
Most collaboration involves artifacts that may be worked on synchronously andasynchro-
nously, each at different times, as part of different phases of collaboration. Further, since
authoring work styles are often opportunistic (Beck and Bellotti 1993), explicit access con-
trol may block useful activity whether this control takes the form of a predefined workflow,
or is a consequence of automatic system synchronization policies. The Prospero toolkit
In addition to the inherent research interest that synchronous computer-supported work
has (as the most “revolutionary” way to apply technology to the problem), the prevalence of
toolkits for synchronous work reflects the technical difficulty of supporting real-time inter-
action (and the consequent attractiveness of the problem to researchers). The most popular
model for synchronous interaction (the WYSIWIS or “What You See is What I See” paradigm)
makes heavy performance and consistency demands. Even toolkits like Suite, which allow
less tightly coupled interaction styles, are dominated by the mechanisms needed to support
synchronous, consistent interaction. That the performance implications of these approaches
are so different is one obvious technical reason that this split between systems has persisted
for so long. More fundamentally, computer implementations supporting asynchronous work
differ radically from implementations supporting synchronous work, because, in order to
guarantee consistency, asynchronous systems must generally accommodate the possibility of
inconsistencies arising during off-line work, or impose a work style involving the explicit
management of access via locking or rollback. While locking and rollback can still create
anomalies in the user interface of synchronous applications (Greenberg and Marwood 1994),
these mechanisms have been applied in the design of synchronous applications in order to
guarantee consistency, and reduce the impact of inconsistency.
However, recent research has clarified what might seem to be an obvious point about the
usefulness of dividing work into separate classes of synchronous and asynchronous (Dourish
1995; Dourish 1996). While current applications are often oriented to one or the other of
these modes of work, projects themselves are not split this way in actual work situations.
Most collaboration involves artifacts that may be worked on synchronously andasynchro-
nously, each at different times, as part of different phases of collaboration. Further, since
authoring work styles are often opportunistic (Beck and Bellotti 1993), explicit access con-
trol may block useful activity whether this control takes the form of a predefined workflow,
or is a consequence of automatic system synchronization policies. The Prospero toolkit
