Autosaving is commonly known as a behavior where an application automatically saves the current document when a change is made. This prevents any loss of work if there is some unexpected catastrophe or just a tiny mishap like accidentally navigating away from the document in the browser.
This was what customers asked for in their feature requests and it is how the initial requirement was defined.
The central activity of autosaving a document is — when successful — transparent and silent to the user. This makes it appear deceptively simple.
However, autosave created new consequential problems in Alpine Chorus that needed to be solved to make the feature friendly and usable.
Consider the typical usage scenario: a data scientist is working on their project. Creating a machine language workflow is an iterative process, with many cycles of trial, test, and refine. After a few hours of work, she (the data scientist) updates one of the operators in the workflow to change the linear regression tolerance from 0.000052 to 0.000039. The application silently autosaves the changes for the user. Now the data scientist re-runs the workflow to see how the results are affected, and since the run takes 21 minutes (not unusual for big data analytics), she works on something else while waiting. When the run is finished, she reviews the results, and decides that the original setting was better.
What does the data scientist do when they realize the change needs to be changed back to the original settings?
Since the document was autosaved, the new setting has already been saved. The data scientist could manually enter the earlier setting, but
Requiring the user to manually change the parameters back to the original, but that means the user has to remember what the setting was. That is unusable, untenable, and unfriendly. Reverting the entire document to the how it was when it was first opened is another option, but it is insupportable because it forces all the other work to be discarded. What is needed is the ability to undo an individual change. Autosave cannot exist in a usable manner without undo.
A successful user experience for autosave required designing a holistic set of features and application changes that are linked together, though none of them are initially obvious.
Each of the pieces of the designed solution are connected to the others. They work together to form a more comprehensive user experience, better together than on their own. Each needs the other.
As a holistic system, the complete autosaving design works like this:
When a workflow document is opened, it will be locked to that user, so that other users will not be able to edit and make changes that could be overwritten. For the person working on the workflow, changes made to the document (since it was opened) are recorded in a history log, and the user can undo or redo, sequentially or non-sequentially. Meanwhile, all changes are automatically saved by the application, silently. When the user is finished working and closes the workflow, a new version is created. Alternatively, the document can also be saved as a new file.
Document changes are saved automatically, constantly, and transparently (without interrupting the user).
Individual changes made to the document are recorded in a tabular log, along with a brief description of what changed.
Sequential changes can be undone or redone from the workflow view. Alternatively, the user can navigate within the history log to undo or redo changes non-sequentially.
When a user opens a workflow, that workflow is locked, and other people cannot make changes to it. The lock is released when closed or can time out due to inactivity.
During the process of designing the primary autosaving behaviors, additional changes were discovered to also be necessary. Less obvious than the main features, these supporting pieces are nevertheless integral to the complete user experience.
Save the current document as a new file. The need for “save as” was recognized during the design iteration process in order to support how teams work together.
The document owner information is made visible and actionable. This is essential information for team collaboration and communication: If a workflow is locked, another team member needs to know how to contact the owner.
Editor UI Structure Changes
The existing interface layout was not originally designed to be flexible nor to accommodate additional user-facing actions. New features required changing the basic structure of the interface.