Design Pattern Library: User Feedback/ Interaction for Automatic/Unobtrusive persistence of data vs. manually saving
Many of our forms/settings pages save data in different ways. Sometimes data is saved automatically, sometimes the user needs to click save. From a UX perspective, the experience is inconsistent. This issue is to drill down how, where, and why data would be saved automatically, and where it would not be. This paradigm should include informing the user of saved data, as well as a way to Undo
in certain circumstances.
This includes:
-
Submitting a web form versus inline saving
-
Button states and styling
-
Other labels / UI to indicate changes in state (Error Handling)
-
Round-trip server processing versus instant feedback
Solution
Auto save
- is best for saving changes in individual fields
- if the field is a text field, we can automatically save x seconds after the user stops typing and on blur event
- we communicate that the change is saved with a toast message at the bottom left of the screen
- in the toast message we provide the option to undo the change
- we only show one toast message at a time, we don't stack them up
Here's how that would look:
The input field with changes is still focused but x seconds have passed and the changes were saved.
On mobile, we could display toast messages below the nav bar so we avoid the case where they would be hidden behind the keyboard.
Guidelines
-
These are good for long pages with settings as the user doesn't need to look for the 'Save' button to confirm changes.
-
Never apply to whole forms. Example: Adding a personal access token needs a name, expiration date, and access scope.
-
Apply to data that only affects the user editing it. Example: user preferences
-
If the data affects other users, make sure that the user is conscious of entering/leaving the editing mode and saving the data. Example: Editing issue fields
-
Never apply to data that might have financial, security, or privacy impacts. Example: Changing password or changing an issue's confidentiality
Saving drafts
- should only be used in certain cases: issue comments and descriptions (as is now) and other cases when long texts are expected.
- we should show the background activity of saving with a spinner
- when the draft is successfully save we need to communicate that. A simple 'Draft saved' or 'Saved just now', 'Saved x minutes ago' is enough to reassure users that their progress won't be lost.
Indicating save progress | Indicating 'draft saved' |
---|---|
Guidelines
- Think twice before applying to data that might have financial, security, or privacy impacts. Example: We wouldn't save a draft of the user's new password.
- Think about how helpful saving drafts is in every case individually. Try to limit this approach for cases when expected content is long and losing any progress would really hurt user's experience.
Manual save
Manually saving changes should remain the default option. The other two approaches should be used if they contribute to improving the user's experience, if you think it would add confusion to the process, default to saving manually.
Safety measure
As we move towards using all three approaches, it makes sense to add a safety measure when using the manual save approach. The user might just experience auto saving on another page but on the current page we use manual save approach. So it's possible that the user makes changes and tries to navigate off the page (expecting that the changes are automatically saved). In such cases we should track the changes made and wether they were saved or not. If they're not, a modal should appear asking: 'Your changes are not saved. Do you want to save them now?' Similar to how Chrome warns users when they want to close a tab where some content has not been submitted yet.
Round-trip server processing versus instant feedback
We should use instant feedback in cases when successful result is expected, examples: changing an assignee on an issue, changing the milestone, due date, time tracking, epic, weight etc.
The new information should be added imediately but we should indicate that there's background activity for saving the change. To do that, we should combine opacity and using a spinner. I recommend we use 50%
opacity and the dark spinner for such cases:
In the follwoing case, the whole row in the table of badges is at 50% opacity and the spinner is located next to the title of the section ('Your badges').
Once the change is successfully saved, the opacity changes to 100% and the spinner disappears. Afaik, we don't have a way of handling errors for such cases atm. We keep persisting until it gets successfully saved. Should we have a safety measure, similar to the one I described in the 'Manual save' section? The message could be 'Something went wrong with saving changes to the assignee. Retry?'
Plan
Next steps:
- add to the design system in 11.5
- try to redesign a settings page (Profile settings?) with these guidelines in mind (11.5 or 11.6?)
cc/ @cperessini @pedroms @tauriedavis @dimitrieh @hazelyang @victorwu