Autosaving Web Forms

Hi everyone! We’re currently exploring autosaving and recovery behavior for Web Forms and would love feedback from the community before we finalize anything.

The concept we're currently considering is to save a draft locally in browser storage while a form is being filled out. If the tab is closed before submission, the local draft will be restored next time that same form is visited. Project managers will be able to turn this behavior off from Central but it will be on by default.

We’re currently thinking about a few related UX questions:

1. If autosave has been configured by the form/project owner, should enumerators still be allowed to disable it locally in the browser?

  • For example, maybe they’re on a shared device, have storage/privacy concerns, or simply don’t want recovery enabled.
  • Or should autosave always remain enforced once configured?

2. What do you think about a silent recovery flow for autosaved drafts?
If the browser automatically restores in-progress answers after refresh/crash/reopen:

  • no confirmation dialog is shown
  • recovered answers automatically expire after 30 days

Would this feel helpful and seamless, or surprising/confusing? Would you prefer a “Recover” prompt instead?

Are there other offline autosave/recovery behaviors we should think about?

As always, looking forward to hearing everyones thoughts!

I think it's important that the end user has the ability to disable, for all the reasons you stated. Manually clearing this data is possible but technical and difficult to do. Incognito mode works but you have to remember to turn it on before starting on the form.

Automatically loading the draft would be surprising to me, so I prefer an explicit action.

It's also worth considering this in the context of other offline information, such as last-saved and offline submissions and entities. Does it make sense to have one setting which enables/disables all of these data stores, or do we need fine grained control over which are on or off?

@norlowski and I had another discussion about this following @gareth's feedback and are now leaning towards making browser-based autosave off by default. It may be hard for project managers to fully understand the data security implications and the functionality may slow down large forms. We can choose to make it the default behavior after it has been available for some time and we have polished it.

How about we start by mitigating data safety risks by making the entire functionality opt-in for now and keep end-user signaling and possible disabling as a possible later addition once we better understand what kinds of projects opt into the behavior? @norlowski and I think the functionality and its implications are going to be difficult for most end-users to understand.

I think we need a setting for just this functionality.

Last-saved is only useful in a context where a user will be filling out the same form multiple times and it's already opted into by project manager through form design.

Allowing forms to launch offline and have a send queue feels like separate functionality that we want to give project managers the option to specifically opt in or out of.