I'm working on a web app which heavily uses modal windows to display forms/options for different tasks. Some of the modals have a one time only 'confirm' action which warrants a 'success notification' being displayed to let the user know everything worked as it should.

Is there a best practice to how/when the notification should display?

Should the notification appear within the modal, then the modal fade after 2-3 seconds or is closed by the user.

Should the modal be deactivated upon click and the notification displayed on the previous page?

4 Answers
4

I believe the issue really depends on the context and the users expected action.

If the user is working inside a modal that they have to enter in information once, then displaying the message on the previous page would be better. This is because users should not be forced to close the modal on there own. On the previous page the success message can appear and its up to your discretion weather or not a too fade the message away after a period of time or have it stay on the page. See mockup below:

If the context of the modal is a system where the user must or most likely will be entering in multiple entries at on single sitting; displaying the success message at the top of the modal for every completion is prolly enough. Being a user would not want to have to open/close the same modal for every entry. See mockup:

I suggest changing the button text to "Saving" or similar. This way the message is right where the user clicked and indicates a response to the action. That is good feedback. Be sure to make the button disabled so another save call can't be made.
Fig 3

I put the success response in context of the action. A few reasons?

The modal can be various sizes and the button could be low on the screen. the message will never be in the same space. Also, People expect the modal dialog box to go away when the action is complete. Having it hang a round for a message is like leaving the party too late. People will be busy the wondering why there was no response and won't read your message.

Put the success message on the page, either in context of the saved item or in a consistent and visible spot on the page. Fig 4. This way the users will get the feedback the expect from a saved modal and a consistent feedback message placement.

Broadly agree with this concept - users expect modals to dismiss, and putting notifications in the context of host content that's being edited is a good pattern. You hit on a good point about the disappearance of the model itself being a kind of success notification.
–
Jimmy Breck-McKyeAug 31 '12 at 11:21

You said it better than I but yes the "feeling" people get from something working correctly provides much better feedback than the contrivances designers put to indicate success. For example, if you close your car door to lightly. The off sound it makes will let you know it wasn't shut right long before you notice the red light in your dash. A modal closing is the equivalent of that car door closing right.
–
ItumacSep 1 '12 at 3:47

I'd say attach the message to the modal as it related to information IN the modal. If you put it on the previous page it will then become associated with the content/actions there i.e. the thing that triggered the modal rather than the actions performed in the modal itself.

Don't forget WCAG Level A 2.2 - Provide users enough time to read and use content

As an aside, I'd recommend covering up the button pressed with the success message. The user's eye is already focused there and it stops them trying to press again out of confusion should they not see the feedback (solving the same problem twice). A countdown could make it even more obvious.

Modals are usually used for data input when they affect the content of the host page. Any success messaging, then, should make clear how the actions in the modal have affected that content.

For this reason, it may be better to place modal notifications in-situ; near or next to the content that has been updated, and to use visual clues that the content has changed (a fading highlight, for example).