38

Some forms could take a while to save (internet speed, slow data validation...) and there is the need to show that the system is saving the data while locking the form from further edits.

  1. Is there a better pattern among the following two ideas?
  2. Are there differences between mobile and desktop on this?

Option 1 - notification above form

enter image description here

  • Display a notification like "Saving" (with a spinner) covering the entire form. (This would lock the form from further editing while saving. Also the buttons get disabled)
  • Then the notification can turn into "Saved" (with big green checkmark)
  • Dismiss modal/close page

Option 2 - small notification inline with button

enter image description here

  • Use a "Saving" message inline with the saving button (while disabling form and buttons)
  • Confirm that the form is saved replacing the notification with a "Saved"
  • Dismiss modal/close page
Improve this question
10
  • 10
    Whatever you do, make sure the user can't submit twice. There are all kinds of trouble ahead if that's allowed, with or without modifying the content in between.
    – Mast
    Commented Mar 10, 2020 at 9:12
  • Why are the buttons (and input fields) disabled in step 3? In step 2 it makes sense, but in step 3 the user may want to edit the form a second time and then save again.
    – allo
    Commented Mar 10, 2020 at 14:27
  • @allo the idea is that the modal gets dismissed some milliseconds after the green "save" notification. So to edit the form again the user needs to repeat the action that triggered it in first place.
    – Andrea Avesani
    Commented Mar 10, 2020 at 14:32
  • Pressing a Save button is old fashioned, it is what feeble systems do. Autosaving and doing away with the reliance on the User to save as they go = modern. Either Done or discard/cancel, but why save?
    – straya
    Commented Mar 11, 2020 at 1:34
  • 1
    Also consider what happens during an error state, the application may try to save for 30 seconds, until it sees that the internet connection is lost (there are often cases where you cannot detect and internet connectivity loss without timing out)
    – Ferrybig
    Commented Mar 11, 2020 at 15:25

6 Answers 6

Reset to default
52

Option 2 leaves the modified content in place and visible. It means that your users don't have to recall the data they just submitted / modified.

Inline notification (Option 2):

  • Does not make the user recall/remember the data.
  • Keeps the modified data visible, allowing the user to catch any mistakes they may have made
  • Keeps the state indicator ('Saved') in close proximity to the disabled buttons, where my eye is when I select Save

Option 1 makes it obvious that something has been saved, but puts the load on the user to recall what they just saved.

As for question 2, this may be more of a layout question.

Improve this answer
2
  • just to note, it's also possible to show option 1 (middle frame) while the save is in progress, making it abundantly clear what is going on, but then go back to option 1 when saving is complete, so they can see what was saved and correct if needed.
    – Michael
    Commented Mar 11, 2020 at 2:07
  • Good answer. But what is when the user want's to navigate away while the save process is still going? Let's say above the form is a navigation of the website. The user presses "Save" and immediately clicks one of the navigations before the form is saved. How to prevent this? Option 1 would prevent this.
    – Michael Schmidt
    Commented Jul 8, 2020 at 15:30
25

Option 2 is better, as discussed by Mike M. I would actually recommend a third option, similar to Option 2. I would replace the "Submit" and "Cancel" buttons with the "Saving" message and spinner. This ensures the first thing the user sees is the "Saving" message. When a user presses the button, their eyes will linger there until something else catches their attention, so you want the change to happen right there. Just greying out the button makes the form look "possibly broken", until the user looks around and sees the "Saving" message.

The advantage of Option 1 is that the user knows they can no longer change their answers. I would recommend putting a grey background behind the text entry fields, to make clear that the user can't edit them. (I would also make sure the user can't edit them).

Improve this answer
2
  • 8
    Replacing the buttons with message will save space in mobile view also.
    – Sp0T
    Commented Mar 10, 2020 at 5:31
  • 4
    Need to be extra careful that whatever UI you're replacing has exactly the same size as what you replaced. Otherwise you get this this motion on the page that feels very unclean
    – Cruncher
    Commented Mar 10, 2020 at 19:28
10

What I've found works best for my use case is to, like @Hugo-Viallon suggests, put the spinner in the save button and disable all other buttons. After completion I show a toast if the user isn't redirected.
Without the toast I had users saving multiple times just to make sure it worked, a small confirmation helped prevent that.

preview

jsfiddle

Improve this answer
3
  • 6
    I think my preference would be to replace the "Save" button with "Saved", and have the text change to "Save" if anything in the form is edited.
    – supercat
    Commented Mar 10, 2020 at 16:56
  • 1
    @supercat That would be nice, the buttons could also be disabled if nothing has changed.
    – GammaGames
    Commented Mar 10, 2020 at 18:35
  • 1
    @supercat I think this depends on the particular use case. If the form is going to be commonly saved multiple times throughout one session, then having the button display "Save" immediately after a successful save is important. But yes, if that's not a common use case, then displaying "Saved!" or even automatically transitioning to another step is better
    – Cruncher
    Commented Mar 10, 2020 at 19:31
4

You could have a variant of Option 2 :

The loading could be put on the "Save" button, as a spinner that'll replace its text. You also disable buttons.

This way you show that something is happening, and the spinner being on what was the "Save" button tells the user that something is happening. The other buttons being greyed out make it even more obvious that clicking "Save" did an action.

Lastly, this avoids removing buttons and messing with the existing layout.

Improve this answer
1
  • While this is a nice idea visually, getting assistive technology to convey this information (in HTML/JS) is a pain unless the notification in option 2 is implemented alongside albeit in a visually hidden manner, in which case I might as well just go with option 2.
    – rink.attendant.6
    Commented Mar 10, 2020 at 23:40
3

If the text field can contain more than a very few words, then better not hide it, and better not make it unselectable either.

It's very annoying if I fill out a large text/comment field, hit submit, the saving icon is animating, animating, animating, then the connection drops or some other error occurs. If my screen wasn't hidden, I could at least select what I've written, copy it to the clipboard, reload the page, paste it, and try again.

By removing this option, you are making your users lose their work whenever anything goes wrong with the saving process.

Improve this answer
0

I'd go for a different approach (so basically, I'm answering question 1): Upon clicking submit, hide both the form + buttons and show a textual summary of the data the user submitted before actually posting the data, while also providing feedback about the process (maybe a spinner, but I'd prefer something less infinite and a color coded label that describes what is happening/has happened, eg "Submitting/Submitted/Error").

Why I'm in favor of such an approach:

-As the post only happens after hiding, chances to send a duplicate request are lower, even if the user is Click Eastwood, you can easily catch multiple clicks and deal with them before requesting

-It becomes very clear that the form was posted and can't be changed anymore

-The user gets rewarded for his action with a significant change of the layout

-Most users will read the summary while waiting, hence softening the wait and giving them the time to spot errors to rectify them later on

Improve this answer
1
  • HTTP idempotence is the best way to deal with Click Eastwood, don't ruin the frontend and instead try to address the source of the issue.
    – straya
    Commented Mar 12, 2020 at 0:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.