A Temporal Model for Multilevel Undo and Redo

1. 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

2. 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)

3. This Research Deals with two issues: • Representing causal effects in application timelines • Representing timelines that can be “decomposed” into multiple constituent parts

4. Putting This Work in Context Simple Undo/Redo Stable Time Editable Time Chimera

5. Putting This Work in Context Linear Divergent Version Control Simple Undo/Redo Stable Time Editable Time Timewarp Chimera

6. Putting This Work in Context Linear Divergent Single-level Version Control Simple Undo/Redo Multi-level This Work Version Control Stable ? ? Editable Timewarp Kurlander

7. 0 1 2 Draw A at X, Y Move A to X’, Y’ Resize A to W, H Background: Representing TimeWith the CommandPattern • 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…

8. 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

9. An Example: Map Behavior

10. 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…

11. 0 3 1 4 2 Draw New Stroke A’’ Erase Intersected Stroke Draw Original Stroke A Erase Stroke A Draw New Stroke A’ 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

12. 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

13. Logical Timeline End TA Start TA Nesting Depth Start TC End TC Start TB End TB 0 1 2 Transaction Stack B C A

14. 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

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

16. Boards and Segments • Flatland UI consists of • A “root” surface • Individual “segments”containing strokes andassociated behaviors • Segment specific time • Traverse time in onesegment, while othersstay fixed • Global time • Traversing global time “snaps” all segments to the current global time

17. “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

18. A local history comprises only the operations from a single timeline. Local Timeline 1 Local Timeline 2 Local Timeline 3 The global history comprises all operations from all local timelines. Local versus Global Timelines

19. 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

20. 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)

21. Local 1 Global Local 2 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!

22. 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)

23. 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

24. 0 T1 1 0 T2 1 0 Tglobal 1 The “Push” Transformation Without Transformation: Local timelines contain aligned, toplevel transactions. With Transformation: Local timelines still contain aligned, toplevel transactions. 0 T1 1 0 T2 1 Assembly & Transform Assembly 0 Tglobal 1 2 3 Contained transactions are re-nested. The global history is now aligned. But the global history is misaligned.

25. 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

26. 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

27. 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

28. 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