To make a more robust and user-friendly environment for collaborative analytics in Alpine Chorus, an integrated set of features was designed to add workflow autosaving.
Each separate feature complements and works together in conjunction with the other features.
Project Background
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 Problem With Autosave
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.
The Designed Solution
As a holistic solution, the complete autosaving design system works as follows:
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.
Workflow Document Autosaving
Document changes are saved automatically, constantly, and transparently without interrupting the user.
Why This Is Valuable:
- Eliminate work loss in the case of an asteroid collision, or — more commonly — when the browser back button is used accidentally.
- Long-standing user request.
- Increase enjoyment and trust in the application.
- Improve general impression of application — provides parity with modern applications.
History Log
Individual changes made to the document are recorded in a tabular log, along with a brief description of what changed.
Why This Is Valuable:
- Communicates to the user: gives visibility of individual changes and the progress of overall change.
- Removes the burden of having to remember recent changes. The change description serves as an identifier for the user.
- Directly supports and complements the undo and redo functions.
Undo and Redo
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.
Why This Is Valuable:
- Required to complement the actual autosaving activity.
- Popular user request.
- Increase user enjoyment: makes it easier for a person to work.
- Fulfill user expectations for a contemporary application.
Locking Workflows
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.
Why This Is Valuable:
- People requested this ability to support their organizational processes.
- Solves the problem of having multiple people working on the same file, where changes made by one person overwrite changes made by another person. Before autosave, this problem was comparatively minor, and could be managed manually. When autosave is added it becomes a serious problem.
Supporting Changes
During the process of designing the primary autosaving behaviors, additional application changes were recognized to also be necessary. Less obvious than the main features, these supporting pieces are nevertheless integral to the complete user experience.
“Save As”
Save the current document as a new file. The need for “Save As...” was identified during the design iteration process in order to support how teams work together.
Workflow Owner
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.
Interface Elements
