One of my projects at PARC was an infrastructure for building collaborative applications called Timewarp. Unlike many collaborative tools, which are designed to support “synchronous” or real-time collaboration, Timewarp is designed to support the construction of tools for what might be called autonomous collaboration.
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 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.
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 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:
(For a more complete list of my publications, go here.)