a temporal model for multilevel undo and redo w. keith edwards……….xerox parc takeo...

A Temporal Model for Multilevel Undo and Redo

W. Keith Edwards……….Xerox PARCTakeo Igarashi……...Brown University*Elizabeth D. Mynatt…….Georgia Tech*Anthony LaMarca………………Yahoo!*

* PARC expatriate

The Setting

How to create applications with a rich, flexible, and interactive model of time?– Simple example: undo/redo– Not so simple: modifiable time (e.g.,

Chimera)– Not so simple: divergent time (e.g.,

Timewarp)

This Research

Deals with two issues:• Representing causal effects in

application timelines• Representing timelines that can be

“decomposed” into multiple constituent parts

StableTime

EditableTime

SimpleUndo/Redo

Chimera

Putting This Work in Context

Putting This Work in Context

StableTime

EditableTime

SimpleUndo/Redo

Chimera

Linear Divergent

VersionControl

Timewarp

Divergent

SimpleUndo/Redo

Kurlander

VersionControl

Timewarp

Linear

Stable

Editable

This Work

? ?

VersionControl

Single-level

Multi-level

Putting This Work in Context

Background: Representing TimeWith the Command Pattern

• Each node represents an atomic operation– Can be rolled forward or back– States are the “spaces” between nodes

• Anecdotally: much of the trouble of building apps in this pattern comes from the “atomic” part…

Draw A at X, Y

Move Ato X’, Y’

Resize A to W, H

0 1 2

Case Study: Flatland

Atomicity was a showstopper• User inputs “primitive” ops

– drawing and erasing strokes

• “Behaviors” act on stroke input– An example: map behavior

• The user-visible operations implicitly occur as side effects to the original input– Operations of the behaviors should be hidden

An Example: Map Behavior

Representing Cascading Operations—Three Choices

• Represent all operations in the history– …including operations put there by behaviors

• Only store original input– Requires “replaying” history to rest of application– Not self-describing, expensive, difficult search

• Create new commands representing all possible combinations– Combinatorial explosion…

We took the first approach, but…

Side Effects Become “Foreground” Effects

So now what we have is:

• “Implicit” operations are now foreground.• Atomic movement no longer gives us what we want• Need to explicitly “chunk” the timeline to represent

causality– Maintain benefits of command pattern, but hide implicit

operations

Draw NewStroke A’’

EraseIntersected

Stroke

3 4

DrawOriginalStroke A

EraseStroke

A

Draw NewStroke A’

0 1 2

Transaction Scopes

• Group related operations into causal groups

• Each original user input begins a new scope

• Transactions can be arbitrarily nested• Completion of “side effect” operations

signals the end of a transaction scope• Transactions—not individual operations—

are now the new unit of atomicity

NestingDepth

0

1

2

Start TA

Logical Timeline

End TA

Start TB Start TCEnd TB End TC

AB CTransaction

Stack

Related Work: Hierarchical Events

Some similarity to work by Kosbie and Myers (1993), but:– Difference in goals:

• Hierarchical events impose interpretation• Transactions reflect causality

– Difference in mechanism:• “Higher level” events are assembled bottom-up• Transactions collected top-down

– Difference in experience:• Hierarchical events facilitate undo at any level in the hierarchy

(user visible operations)• Causal model side effects are “implementation details” and

should not be exposed individually

…And all was fine, until we decided to add a new feature…

Boards and Segments

• Flatland UI consists of– A “root” surface– Individual “segments”

containing strokes andassociated behaviors

• Segment specific time– Traverse time in one

segment, while othersstay fixed

• Global time– Traversing global time “snaps” all segments to the

current global time

“Multilevel” Models of Time

• Each segment maintains its own “local” notion of history– Traversing time in a segment does not affect any

other segments– The local segment is in a “bubble,” separated from

other changes– Useful for long-term work in a given segment

• The board as a whole maintains a “global” notion of history– Changes to the global history “snap” all segment

timelines to the new global time– Useful for reverting to past whole-board states

Local versus Global Timelines

Local Timeline 1

Local Timeline 2

Local Timeline 3

A local history comprises only the operationsfrom a single timeline.

The global history comprises all operationsfrom all local timelines.

Multilevel Time Interacts with Transactions

• In atomic models of time, interleaving can be arbitrary– Can “jump between” local and global timelines

freely

• But this isn’t the case with richer, causal models of time– Don’t want to jump in partially completed

transactions– Some ops may have side effects in other

timelines– Potentially arbitrary interleaving of timelines

An Example

• Consider an operation in segment S1 that changes segment S2– A transaction is still open in S1…– …but a new transaction is started in S2

• Locally, timelines consist of sequential toplevel transactions

• Globally (“real” time), transactions are interwoven!

• Not unique to Flatland– Version control operations to move files to other

subprojects (atomic, in this case)

Why is This a Problem?

• While the local timelines align on transactional boundaries, the global timeline does not– Top-level transactions in distinct timelines overlap– “Real time” does not consist of sequentially ordered transactions!

Global

Local 1

Local 2

A Solution

• What “should” happen? (Example)• Within a local timeline, we’ve already got

sequential, consistent transactions• Need to “repair” global timeline in a way

that preserves causality– Turn segment-spanning operations into a single

transaction, globally– If an operation in T1 is the cause of any effects

in T2, T2 is causally dependent on T1 (globally)– (Even though, from T2’s perspective, it is a

standalone op)

A Solution (cont’d)

• Globally modify timelines to “push” side effect operations that span timelines into a higher nesting depth in the global timeline

• Reflects the sense that the “global” timeline captures cross-segment changes as single operations

But the global history is misaligned.

Without Transformation:Local timelines contain aligned,toplevel transactions.

With Transformation:Local timelines still containaligned, toplevel transactions.

AssemblyAssembly

&Transform

Contained transactions arere-nested. The global historyis now aligned.

T1

Tglobal

T2

0

0

1

0

1

1

Tglobal

0

1

T1

T2

0

0

1

1

2

3

The “Push” Transformation

Flatland Implementation• All navigation machinery stays the same

to accommodate these new semantics• Only change is a transformation executed

during the construction of the global timeline– Identify and “push” segment-spanning

causality– Global timeline derived from local timelines

• Accommodates local and global timeline manipulation

Search Over Time

• Flatland provides two time-search tools– Visual scan via scrolling– Query-based search

• Much to be gained by representing all operations explicitly in the timeline:– A stable representation of all changes– No need to “replay” computationally; just reset

the application’s state– Can pattern-match the timeline for interesting

prior states– Nodes can cache thumbnails or other

representations of state– Time-based semantic snapping

Conclusions

• Extensions to the command pattern for representing application time– Explicit representation of causal effects– Transformational model for applications with a

“multilevel” model of time

• Explicit representations afford search• Work still to be done on multilevel time:

– Editing of multilevel timelines– Divergent multilevel timelines

Local versus Global Timeline Management

In this implementation,– Traversing local timelines does not affect other

local timelines• Local timelines can be manipulated in a

“bubble”

– Traversing global timeline “snaps” all local timelines to current global time

• No isolation of individual timelines from the global time—only from each other

– The ability to freeze a segment while reverting the rest of the board could be a useful feature…but our model does not support it