Saving is an action the user takes when they want to create a resource or save changes to existing resource. Users need appropriate and timely feedback when they save their changes to give them confidence the action is reliable and effective.
When saving occurs
- Saving occurs when a user clicks a button with a Save label. This is typically when a resource is created or updated.
- Users should be making deliberate choices to commit to their changes. For that reason, we don't auto-save users' work. We prefer to provide manual saving actions for users to save when they are ready.
The elements of the save pattern
A save process is typically four steps. Save, saving progress, redirect and confirmation.
1. Save

The save button should always be a primary button (green). It should be positioned either (1) in the top-right of the paper element or (2) bottom-right of a save dialog. The label should be 'Save'. The save button should be disabled when no data has been changed to signify that nothing has changed. The button should become enabled as soon as the user edits the data.
2. Saving progress

After the user clicks the save button, the 'Save' label should change to 'Saving' and a linear progress indicator is displayed on the top of the paper element or dialog (depending on where the task originated from).
3. Redirect

After a successful save, the user should be redirected to the resource they just created or edited. This redirect is for convenience, as generally the user will want to edit that resource. Any expanders on the paper element become collapsed. When a user creates a resource in a dialog they should be redirected to the detail page for that resource (e.g. when creating a project). The exception to this redirect pattern is when a user clicks save when they are trying to navigate away from an unsaved resource. In this case, we show a dialog for the user to decide if they want to save their changes. The user should be redirected to the page they attempted to navigate to after the save has persisted.
4. Confirmation

The user should receive visual confirmation after a save action. A successful save presents a snackbar (pictured below). A failed save presents the error handling pattern. Once the save action has been performed and the page has redirected, a snackbar appears at the bottom of the screen with a message 'Details updated'. This message can be customised as needed.
Best practices
Do
- Use a primary button for save buttons. The save button should always be a primary button (green).
- Disable the save button until data has been changed. The save button should be disabled when no data has been changed and enabled as soon as the user edits the data.
- Redirect the user to the resource after a successful save. After a successful save, the user should be redirected to the resource they just created or edited.
- Provide visual confirmation after a save. A successful save presents a snackbar and a failed save presents the error handling pattern.
Don't
- Use labels other than 'Save' for the save button. When creating or editing a resource, the button label should always be 'Save'.
- Place save buttons in arbitrary locations. The save button should always be positioned either in the top-right of the paper element or bottom-right of a save dialog.
Scenarios
The following scenarios outline the vast majority of saving actions in Octopus Deploy. Once the save is successful they should be redirected to the detail page with a snackbar message.
Saving changes to a resource on the paper element

The user wants to save changes they have made to a form on the paper element. The save button should be visible in the top-right of the paper element.
Creating a resource on a save dialog

The user opens a dialog to create a resource. The dialog should have a save button in the bottom-right.
Navigating away from a page with unsaved changes

When a user attempts to navigate away from a page with unsaved changes, we prompt them with a dialog to give them options for saving their data. The save button on this dialog is a secondary button style. Cancel is the primary action because it's the least destructive.