¶
Autonomous collaboration captures many
of the common working styles that we use when collaborating in the real
world. The basic notion is that the participants work more-or-less
independently on some loosely-shared artifact. By independent, I
mean that the collaborators do not necessarily see (or are bothered by)
the work of others. By loosely-shared, I mean that the artifact that
the participants are working—a shared paper, drawing, etc.—is not necessarily
in a completely consistent state across all of the collaborators.
Time, Parallel Universes, and Divergence
¶
Timewarp provides this “insulation” between
participants by making the notion of time both explicit and malleable.
That is, in addition to working directly with the shared document, participants
in a timewarp session can “travel” back in time, review earlier states
of the document, change past events (essentially re-writing history), create
forks in the timeline, and so forth.
¶ One fallout of the ability to edit time is that users can make “contextually-appropriate” changes to their shared documents. As an example, consider collaborative paper writing. In the “real world,” I will typically print copies of a first draft, and give these out to colleagues to review while I continue to work on the draft. When these copies come back to me, they refer to a version of the document that no longer exists. Using Timewarp, I can “recontextualize” these changes by applying them directly to the version of the document they refer to. Any changes made earlier in time will “ripple” down the timeline and update my current copy appropriately.
¶
Autonomous collaboration requires divergence—the
ability to support different but related versions of the views and data
at each participant. This divergence, which typically happens implicitly
in a weakly-consistent distributed system, is explicitly represented
in Timewarp as forks in the timeline: Timewarp allows any number
of
plausible alternate histories of
the shared artifact to exist at once. Users can see and control this
divergence by interacting with the timeline.
Paradoxes of Time Travel
¶ Certainly, the ability to travel back in time and change the past is not something we typically experience in the everyday world. But it has been explored in science fiction, and the ability to “edit time” in Timewarp gives rise to many of the same paradoxes we see in books and movies. (But, as good computer scientists, we call these “conflicts” instead of “paradoxes”—much less threatening).
¶ Timewarp applications can, depending on their semantics, choose to actually tolerate conflicts in the timeline. This ability is typically motivated by the desire to favor human convenience over machine inflexibility: if the participants in a collaborative session intuitively understand the state of the shared artifact, regardless of whether it is a state of “paradox,” why should they have to resolve any conflicts just to satisfy the computer?
¶
Timewarp provides an extensible set of
policies for dealing with conflicts. For example, the “explosion
policy” resolves ambiguity whereever it finds it by forking the timeline
at any point of conflict. Each path favors one possible interpretation
of an ambiguous state. As another example, the “quantum uncertainty
policy” manages paradox by associating an “uncertainty value” with operations
in the timeline. As the users add to the timeline by performing new
operations, these operations may reinforce a particular interpretation
of the paradox. As the users proceed they less-favored operations
will become more and more “uncertain” and will slowly fade away over time.
Managing Time
¶
This work has been an exploration of how
explicit and malleable representations of time can serve to support loosely-coupled
forms of collaboration. One of the potential problems with this model
is that most people aren’t particularly used to understanding and interacting
with a complex timeline, especially one like Timewarp can support with
multiple brances, ambiguities, and so forth. Thus, one of the main
themes of this work has been how can be build tools to present time in
an understandable way to the users, even allowing them to “excavate time”
to make sense of a particular history.
¶
Timewarp provides a number of tools for
exploring time. Most of these tools are presented as “magic lenses”
(from the earlier work here at PARC, here). Magic lenses are on-screen
transparent interactors that you can drag over your work surface.
Each type of lens provides a unique effect that can, for example, add to
the on-screen information already presented. For example, a lens
can be used that “annotates” the history view with information about who
performed a certain operation, and when the operation was carried out.
Other lenses can provide explicit details about ambiguity, or act as “filters”
(such as only showing objects created by a given person in a drawing).
For More Information
¶
This is only a rough overview of some of
the basic ideas of Timewarp. The system has been implemented completely
in Java and uses Remote Method Invocation for interprocess communication.
I’ve also revisited some of these ideas in the Flatland project. If you want more details, check out the papers below:
| ¶ “A Temporal Model for Multi-Level Undo and Redo,” W. Keith Edwards, Takeo Igarashi, Anthony LaMarca, and Elizabeth D. Mynatt. Proceedings of the Thirteenth ACM Symposium on User Interface Software and Technology (UIST’00), November 5-8, 2000. |
|
| ¶ “Timewarp: Techniques for Autonomous Collaboration,” W. Keith Edwards and Elizabeth D. Mynatt. Published in Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI), Atlanta, GA, 1997. |
|
| ¶ “Flexible Conflict Detection and Management in Collaborative Applications,” W. Keith Edwards. Published in Proceedings of the Tenth ACM Symposium on User Interface Software and Technology (UIST), Banff, Alberta, Canada, October, 1997. |
|
(For a more complete list of my publications,
go here.)
Back |