Improve Saving Process via Autosave

[joshuajames-smith]

Problem

We currently do not have an autosave which would prevent users losing data unknowingly exiting the platform. This should build/develop/alter upon the physical user save interactions for better UX harmony.

Relates to gliff-ai/dominate#493 - add catch to stop unsaved annotations not saving

Solution

Co-create a userflow which documents the several potential routes of saving. These include:

• hard navigation catch [refresh the browser page, use of the browser back button]
• soft navigation catch [returning to CURATE]
• ANNOTATE trigger buttons [Mark Annotation As Complete, Save Annotation]
• autosave

Considered Alternatives

Think about how Google Workspace handles the saving UX experience (i.e. autosave upon edits).

Additional Context

Relates to #657 - Mark Annotation As Complete no prompt to save annotations
Relates to #658 - Mark Annotation As Complete stay marked complete
Relates to #411 - save and reload system test

[joshuajames-smith]

Further Reading:

• UX Collective – Designing a User-Friendly Autosave Functionality
  (back-end, front-end and UX design)
• Figma – Behind The Feature: The Hidden Challenges of Autosave
  (back-end)
• Stack Overflow – Auto Save Form on Page/Browser Close
  (back-end)
• Code Project – Save Changes on Close of Browser or When Exiting the Page
  (back-end)
• Synthace – Autosave with React Hooks
  (back-end)
• UX StackExchange – How to Clarify Ambiguity in Save Behaviour on Web Based Applications for Users
  (front-end and UX design)
• UX StackExchange – Autosave UI Pattern
  (front-end and UX design)

[joshuajames-smith]

SystemFlow / UserFlow

Design

The below designs align up to key stages within the saving systemflow / userflow. Please let me know of any technical limitations which may impact the intended design. @ChrisBaidoo may want to come onboard to assist some of the styling as there is a few new elements and/or bring these elements into STYLE.

Number 1 – Save Status
This element is a constant feature within the ANNOTATE platform.

In terms of UI, a status icon exists in the navbar next to the file/image name. This icon is a set of 3 which display: saving, save completed and save failed. Each have a hover state which allows users to gain further feedback without this new UI element taking up further visual estate. NOTE: The saving icon should be a small loading spinner.

Number 2 – Connection Warning [snackbar]
This snackbar appears when the user has lost internet connection which would interfere with the backend saving process.

In terms of UI, the red colour (hex code #ED0000) builds into communicating a warning to a user. It is similar to our current snackbar but should use this other copy. In terms of UX, the snackbar should remain on screen until the issue is resolved.

Number 3 – Connection Warning [dialogue]
This dialogue appears when a user attempts a soft or hard navigation when the user has lost internet connection which would interfere with the backend saving process.

In terms of UI, this is our confirmation dialogue which is already used across the platform. There should two buttons which are one primary and one secondary - these use different visual hierarchy to guide the user's decision. In terms of UX, the 'x' will close the dialogue and stay in ANNOTATE where a connection can be awaiting to re-establish connection and the 'Exit without Saving' button confirms the user does not want to save so should cancel the save and allow the soft or hard navigation.

This dialogue is a new state when a user has confirmed they wish to save the changes before the soft or hard navigation.

In terms of UI, the 'Exit without Saving' button should be disabled (aka. greyed out and non-clickable) but the 'Retry Saving' button updates to 'Saving...' with a small spinner. In terms of UX, if the save can be completed as a connection has been re-established then the platform should allow the users intended soft or hard navigation.

Number 4 & Number 5 – Unsaved Changes [dialogue]
This dialogue appears when a user attempts a soft or hard navigation before autosave / save has finished.

In terms of UI, this is our confirmation dialogue which is already used across the platform. There should two buttons which are one primary and one secondary - these use different visual hierarchy to guide the user's decision. In terms of UX, the 'x' will close the dialogue and stay in ANNOTATE where saving can continue and the 'Don't Save' button confirms the user does not want to save so should cancel the save and allow the soft or hard navigation.

This dialogue is a new state when a user has confirmed they wish to save the changes before the soft or hard navigation.

In terms of UI, the 'Don't Save' button should be disabled (aka. greyed out and non-clickable) but the 'Save Changes' button updates to 'Saving...' with a small spinner. In terms of UX, once the save has completed then the platform should allow the users intended soft or hard navigation.

Number 6 – Saving Progress [snackbar]
This snackbar appears when a user triggers a manual save (i.e. 'Save' or 'Mark Annotation as Complete').

In terms of UI and UX, continue to use the current element although I am toying with the idea of overhauling the current saving snackbar due to it's height size. This element gives great user feedback but obstruct the image canvas.

Considered Alternatives

Number 1 – Save Status
I have considered a variety of options towards displaying the autosave / save status to give the user feedback on this constant, back-end process. I focused on finding a balance between communicating enough information to give users security the save has worked and a suitable location which does not obstruct.

Number 3 – Connection Warning [dialogue]
I have considered implementing the red colour (hex code #ED0000) into the dialogue. However, just changing the colour may cause issues with the button - implying a context or 'delete' or 'remove' when it is actually about retrying the save.

[joshuajames-smith]

Updated Design

Following UX discussions, the previous design did not present enough information to the user in a manner which would be understandable without interaction. I have updated the design in response.

Autosave is exclusively an ANNOTATE feature and thus have moved the visual element out of the topbar - removing potential confusion between different products within the platform, i.e. preventing a potential worry from a user why autosave does not exist in CURATE. As such the visual element has been kept small and placed into the top-right corner ensuring the centre of the screen allows enough space for users. There is 3 states: saving (spinner, "Saving...); autosave complete (complete icon, "Autosaved"); and, save error (error icon, "Save Error").