by Auto-Saving is a way to ensure that data provided by a user is persisted without needing them to click on "Send" or "Submit". You may have come across multiple websites that implement auto-saving.
In this short series of posts, we will look at how to implement auto-saving in a simple form while isolating complexity as much as possible.
Should I Use Auto-Saving?
Sometimes, you don’t need auto-saving. It may depend on your application. These are some use cases for implementing an auto-saving form:
- You want your form to be always up-to-date
- You have a really long form that you don’t want the user to lose progress if they decide to close the page
- Sometimes your users forget to hit ‘Save’ in your form, and you want their experience to feel more seamless
However, it’s crucial to understand that a form with auto-saving is always more complex than a form without it. That is because auto-saving forms require you, as a developer, to be a lot more careful when designing it.
In an auto-saving form, if the User Experience is slightly below perfect, the user may still think something is wrong when using it. Next up, we’ll see what exactly we need to be careful of when designing a form like this.
In short, only implement auto-saving forms if you think it’s worth the extra complexity.
Guidelines
Here are a few guidelines and caveats when designing an auto-saving form. Please note these guidelines best apply to small forms used by a single person at a time.
If you’re dealing with a form that can be edited by multiple people simultaneously, you will need to handle potential conflicts. You may want to employ strategies such as Optimistic Locks or Pessimistic Locks to ensure users won’t overwrite each others’ forms.
If you specifically want users to be able to collaborate, you will have to add yet another layer of complexity, involving partial updates and careful conflict resolution. This level of effort might be closer to developing an online collaboration tool such as Google Docs or Figma, which is out of the scope of this article.
Show the User Whether or Not Their Data Has Been Saved
In an auto-saving form, it’s really important for users to feel that their data is persisted. That’s even more necessary if you don’t have a manual "save" button.
If the user has no way of knowing whether or not their data is saved, they might assume that it hasn’t. That leads to them double or triple-checking the save results, to the point where they might simply assume your app doesn’t save their data properly.
An exception is if you want the auto-save feature as a fallback. For example, think of a long form where users are expected to click on "Submit" but you don’t want them to have to type it all again if they close their browser tab before that or if they lose network connection.
Preferably Include a Manual Save Button
A manual save button is helpful to assure users their data has been saved, especially if they are not yet used to the auto-save logic.
Show the Last Time the Form was Submitted
Continuing with the first topic, when showing the save status to the user, it’s a good idea to show when was the last time the record was saved.
By default, some web frameworks include an updated_at DateTime column for records persisted in a database table, which is ideal for an auto-saving form. If the form you’re adding auto-save to doesn’t have that, consider adding it.
However, one thing to be careful with is that these same web frameworks might have a special behavior: they might not update the updated_at value if the record has not changed. That’s fine for most situations, but if you’re displaying that value to the user it might look as if the record hasn’t actually been saved.
It’s recommended that you update this value even if the record hasn’t changed. The Ruby on Rails framework includes a method called touch that forces the updated_at column to be updated.
Be the Least Intrusive as Possible
To help with data consistency, you might be tempted to disable the inputs while the auto-save is in progress. That might work for some cases, but there are situations where the user wants to type in the form again, or they are just taking a break from typing to think about the next sentence. This is especially true for text areas (long text fields), where users might take multiple breaks before resuming typing.
Disabling a form when it has started submitting (even if it’s debounced) might confuse the user. They will either be confused about why they can’t type, or they might not notice it and keep typing. Then, they’ll wonder why some letters or words haven’t been included in the field.
The less the user feels the auto-saving process, the better.
Do Not Refetch Data After Saving the Form
This might be the most important tip.
After you save, it might sound like a good idea to refetch the data after the submission. You might expect the back-end to change the data before saving, or you just want to have the updated data. However, any data refetch can feel intrusive to the user, as it can overwrite the inputs while the user is typing again.
Again, you may be tempted to disable the inputs while the data is being re-fetched, but that will cause the issue mentioned above.
To have the luxury of not pulling data from the back-end after the form submission, you must be sure both the front-end and the back-end apply the same validations, and that the back-end won’t modify the data after the form is submitted.
Some front-end data-fetching libraries such as Apollo GraphQL and React Query may also automatically re-fetch your data, due to the way they handle caching and stale data. Be sure to modify their caching configuration to avoid any data re-fetching.
Consider Notifying the User if They’re About to Leave the Page
Sometimes the user might not realize their data hasn’t been saved. You can add a check of whether or not the user has unsaved data and show a confirmation alert if the user is about to:
- Go to a different page (change the route)
- Close the browser or browser tab
Do not redirect the user if they decline or cancel the confirmation alert.
Add a Loading Spinner or Skeleton Before Loading the Form
This is not directly related to the auto-saving process but can cause issues in an auto-saving form.
If you’re pulling data from the back-end to fill in a form with the already persisted data, you must not allow the user to input data before that’s finished. Otherwise, the user might start typing into the inputs, which will be overwritten by what’s persisted in the back-end.
Prefer using spinners or loading skeletons over disabling the fields, as that better conveys the reason why the fields are unavailable.
Furthermore, depending on how auto-saving is set up, a user typing in the empty fields might cause the auto-save to fire before the loading occurs, causing previously persisted data to be lost.
Investigating Problems in Auto-Saving Forms
During local development, forms load and save a lot faster than in a production environment, since the network latency within your machine is close to zero. Due to that, it might be hard to identify (and therefore fix) any issues revolving around auto-saving.
To get around that, you can simulate a higher latency within your own browser.
Most browser developer tools have a feature called Network Throttling. To access it in Google Chrome / Chromium-based browsers you can:
- Open the DevTools (press F12)
- Select the Network tab
- Click on "No throttling" to change Network Throttling
- Select "Slow 3G"
That will make all network requests take about the time you’d expect from a slow 3G connection. Then, when you interact with the page you can see exactly when the auto-saving happens, and you’ll have a longer time window to attempt to reproduce any bugs you’re investigating.
Wrapping Up
Auto-saving forms can be a pretty neat feature, but can be hard to get right. Hopefully, with these guidelines, you’ll be able to implement what best fits your needs.
In our next blog post, we will implement an auto-saving form that meets the guidelines specified in this article. See you then!
We want to work with you. Check out our "What We Do" section!
