Recovery and Versions
Experimentation depends on a reliable way back. Provisionality makes alternatives possible; recovery makes trying them tolerable. Design for mistakes, interrupted operations and failures as well as ordinary undo.
Undo the User's Operation​
Group changes according to the action the user intended. Dragging a keyframe should normally create one undoable move, rather than hundreds of intermediate positions. A multi-object edit should restore the affected objects together, with a clear description in history.
Keep the meaning of undo consistent across linked views. After moving an object in the viewport and changing its value in the inspector, users should be able to understand which action the next undo will reverse. Make project edits distinguishable from navigation where the application keeps separate histories.
Preserve the redo path when possible, and explain actions that discard it. Users comparing alternatives need to know whether making a new edit will replace the branch they were inspecting.
Distinguish Recovery from Approval​
Autosave protects recent work. An explicit version records a state that someone intends to keep, compare or deliver. A recovered autosave should not silently become the approved version of a shared project.
Label recovered work with its source and time, and let the user compare it with the saved project before replacing anything. Preserve both when the choice is uncertain. Include linked files and dependencies in that comparison; a project file alone may not represent the state that produced the last preview.
After a crash, reopen enough context to continue: project, selection, view, time position and pending work where safe. Report what could not be recovered. Avoid replaying an export, payment or other external operation merely because the interface state was restored.
State the Boundary of Undo​
Writing an exported file, changing a shared asset or running a script may have consequences outside the local project. Before such an action, show the affected scope and available recovery. If undo only reverses the project state, say so; do not imply that it retracts a delivered file or a colleague's changes.
For long operations, provide cancellation with an honest account of what has already happened. Where rollback is possible, perform it as a coherent operation. Where it is not, identify partial output and offer a safe retry.
Restore Part of a Version​
Users may want yesterday's material while retaining today's animation. Where the model permits it, support restoring an object, property or branch without replacing the whole project. Show dependencies and conflicts before applying the restore.
A version comparison should help users identify meaningful changes: an object removed, a source replaced, a frame range retimed. A list of internal data differences rarely answers their question.
Practical check: try a multi-object edit, undo it from a different view, crash during a long operation, and recover an autosave beside an approved version. Then restore one earlier element. Check that the user can explain what was restored, what remains changed and what happened outside the project.