AutoSave feature

August 2020 update
A first-generation Auto-Save Feature was implemented in ODOP release 3.5 (issue and branch #306). The original pre-implementation discussion is preserved below.

Skip forward to Second Generation AutoSave Proposal.

Original Discussion
There are various scenarios in which an AutoSave feature might protect against data loss caused by certain events.
For example:

1. Power failure, system crash or loss of network connectivity (prevents Save operation).
    
2. Most browser users are conditioned to use the browser reload (refresh) button as a means to recovery from various operational difficulties and anomalies. Unfortunately, using the browser reload (refresh) button or browser back/forward with a single page web app such as ODOP will result in a complete reset of the main page and potential loss of a user's work since the last Save operation.

An "AutoSave" feature could work to mitigate the potential loss of work. Different triggers for AutoSave events are possible. For example:

• At the beginning of every use of:
  selected File menu items (Open, Save? SaveAs?)
  every Action menu item (Search, Seek, Trade, Select, Execute)
  Help Tutor & Demo
• After a fixed quantity of time; perhaps user adjustable in preferences
• After a change of state or model (dispatcher)
• After a change in objective function value
• On switching tabs
• On logout

If it is possible to trigger an asynchronous Save operation by monitoring for a change of state, it might be desirable to wait for a period of inactivity before updating the AutoSave. More specifically, it would be desirable to avoid invoking the AutoSave while the user is in the middle of entering a value or in the middle of Search, Seek or Trade.

Of these choices, it seems that the first one (tied to menu actions) is the simpliest and cleanest from the implementation point of view. It can be completely synchronous. Any performance impact will come at a predictable time when the user is most expecting it. There is essentially no risk of capturing an inconsistent state (between user keystrokes, mid-search, etc.). Save points taken before actions like Search, Seek, Trade, Select and Execute are likely to be more meaningful to the user than more randomly triggered save points. In particular, AutoSave points generated by menu action could potentially be used in side-by-side comparisons to better understand exactly what the impact of the operation was.

There is some risk of confusing the role of AutoSave with an UnDo / ReDo capability. See: UnDo / ReDo. In particular, use of Redux features might keep a journal of incremental changes that could support an UnDo / ReDo capability.

It may be possible to keep a set of AutoSave points. Perhaps the user might be able to control how many entries are in the set. The stack of AutoSaves could be reset every time that the user does a manual Save (SaveAs?) operation.

If the AutoSave is based on menu actions, AutoSave design names could be based on:

• unique leading characters (e.g. $!),
• the word AutoSave,
• the currently open design name,
• menu action words like B4Search, B4Seek, B4Trade, B4Sel, B4Exec, B4Open, B4Del,
• a fragment of the current Okta user ID,
• other session-unique information provided by Okta or quantaties such as the session start time or save point creation time

For example: $!AutoSaveB4Search_designname_IDdigitsSessiondigits

Using cookies or Window.localStorage rather than database entries for the physical instantiation of AutoSave data may have advantages:

• higher performance than database entries
• lower database space requirements
• potential name conflict is less of a concern

... and a few disadvantages:

• somewhat greater security concern
• may not work with Incognito / InPrivate browser sessions
• can be inadvertantly cleared with cookie cleanup
• not yet understood consequences of multiple concurrent sessions with the same user ID (public account)

Perhaps a normal exit (sign-out) should remove all AutoSave data. Perhaps a sign-in should look for existing AutoSave data and alert the user that these designs exist and provide a link to instructions on how to recover.

Perhaps it would be useful to have an indicator somewhere near the top of the main page that indicates that the current state has been AutoSaved.

A bit of conversation and a superficial review of web search results suggests that there are at least two main design approaches when implementing AutoSave.

• The "old school" approach involves creating files of a different file name than the current working document. An explicit "Save" or "SaveAs" operation for changes to the current document is required. In this approach, the system is responsible for determining that an AutoSave file can be created without a name conflict.

• The "modern" approach (Google Docs, MS Office 365) involves keeping the current working document up to date with changes as they happen. There is no explicit "Save" operation. This approach is counter-intuitive for users that keep a document file for use as a template. They are typically surprized (and annoyed!) to have their master document over-written to include what were intended as temporary changes. See: principle of least astonishment. One possible way out of this problem is to train users to always duplicate the file that they intend to work on before making any changes. This pushes the responsibility for avoiding name conflicts onto the user and in some use cases requires the user to clean-up the duplicate files that were created for temporary use.

There are issues that need to be thought through:

• Suppose multiple users are active in the same account (particularly, the Public account).
• Suppose the same user has two browser sessions going at the same time.
  Is there a possiblity of conflict on the AutoSave design name ?
• Should a fragment of the user ID string be added to the name of the AutoSave file ?
• Should a time stamp string be added to the name of the AutoSave file ?
• Should the Public account be excluded from AutoSave ?
• if an AutoSave design exists when the ODOP app starts, should it be auto-opened ?

Futures
Should a future, more capable implementation of AutoSave be based on the version management capabilities of Git ?
It may be desirable to have a tutorial-style "back" capability for each of multiple sessions operating in different tabs.
Security issues ?

Second Generation AutoSave Proposal

As of release 3.6, the ODOP icon / logo at the left of the menu & tab bar provides an app Reset function. There is a tool-tip with wording similar to: "Reset app. You should save work-in-progress first. See Help AutoSave".

Proposal:
Invoke AutoSave before the app reset triggered by the ODOP icon / logo at the left of the menu & tab bar. Clicking the icon would create or update the AutoSave data and then trigger a browser reload. If implemented, tool-tip wording can change to something similar to: "AutoSave then reset app".

Proposal:
Expand the list of actions creating or updating AutoSave data to include:

• logout
• tab switching
• after use of the File : Preferences and Properties menus
• other user actions ?

For Discussion:
Consider changing the philosophy of AutoSave. On app startup, rather than providing a "Load AutoSave" button, if AutoSave data is available, it could immediately (no prompt) be loaded as the current design. Note ... consider possible unintended side-effects. This idea needs proper integration with the changes proposed in issue Pass starting Design Type into ODOP #388.