Screen Update / Undo Interaction

Overview

Until now, Screen Updates and Undo Design have been separate design topics. Recent discussions have made it clear that use-cases where screen updates and undo/redo are combined need further thought.

Use Cases

1. A user in "explicit update mode" makes changes to several filters, and hits "update". If they undo, will it undo every change, or one-at-a-time?
   • Suggested behavior: undo all changes at once. Rationale: if the user made several changes before doing an update, it must be because their visualization is slow. Undoing one-at-a-time could be painful.
2. A user in "explicit update mode" makes changes to filters. Before completing the update, the user zooms the camera interactively. Then the user hits "update". What happens?
   • Suggested behavior: the camera zoom is one undoable change, followed by a second undoable change containing all of the filter modifications.
3. A user in "explicit update mode" makes changes to filters. Before completing the update, the user changes the background color on a chart. Then the user hits "update". What happens?
   • Suggested behavior: the chart modification is one undoable change, followed by a second undoable change containing all of the filter modifications.

Alternatives

The above behaviors are consistent with the way screen updates and undo/redo are already designed. They assume that UI behavior falls into one of two categories: interaction that always produces an immediate state change (and thus an undo change set), and interaction that is deferred until the user chooses to explicitly update (producing an undo change set at that time). There are other possibilities:

• Do not allow "immediate" interactions to happen when there are deferred changes pending, e.g: you can't zoom the camera if the "update" button is enabled.
• Do not allow "immediate" interactions at all: camera zoom, chart style modifications, and everything else must participate in the screen update mechanisms.