Memi.Reflection

Private members of memi's thoughts

Action Confirmation in web application

One of the frequent problems we encounter while developing web applications is how to inform the user about an action that has been performed.

Take, for example, the following (quite common) scenario:

A user types data in some textboxes on the page, and clicks the “Save” button. The page submits itself, saves the data in the database, and redisplay. What should happen now? How are we going to inform the user that the save completed successfuly? Basically, we have three options, but IMHO each one of them is not good enough:

1. Display a popup window with the confirmation message - This is a bad alternative, since we force the user to perform some action (clicking the “Ok” button of the popup) without any reason. There was nothing wrong, and nothing should interfere with his regular flow of work.

2. Display a message in the browser's status bar - Not good. Often the browser decides by itself what would be displayed in the status bar, and our custom text could be quickly replaced by “Done”, “Opening page...”, or even “Error on page”. In addition, there is no control at all on the icon that will be displayed. Because of all the reasons above, the average user does not even looks at the status bar - he thinks he already knows what is in there (unlike dedicated classic client / server app).

3. Dedicate special area on the screen for messages - Wrong again. Screen area is an expensive resource, and in web environment it is even more scarce, with all the browser's toolbars (again, not a problem in a client / server app). This solution may work well for applications which should run on high res screens (1024 X 768 and above. Unlikely enough, most users still prefer the old 800 X 600 res) and have very few objects on screen, but if your page contains 10 textboxes + 15 tabs containing textboxes, grids and drop downs (as many of are pages are), you'll think twice before sacrificing 2 cm of the screen for messages which will be rarely displayed.

So, bottom line: we depend on the user to understand that if the page reloaded, and no error message appeared, then everything worked just fine.

What do you think about that? What is your approach to this issue?

Posted: Jul 21 2004, 12:03 AM by memi | with 12 comment(s)
Filed under:

Comments

Jason Mauss said:

#2 isn't such a bad option if you go with some javascript like

window_onLoad(){
window.status = "save complete.";
}

this way the message will be displayed after the page loads and you don't need to worry about the "Done" or "Opening Page..." status getting in the way. If the user's complain about not seeing a message/status about it completing successfully - tell them about the status bar. If they really care about it that much they will remember to look down there - at least for your web application anyway. It's just a matter of user training.
# July 20, 2004 5:10 PM

L M said:

I've been thinking lately about something like the "toast" messages that pop up for different reasons from the tray. Something like having a div "float" up from the lower right corner of the screen, saying that whatever it was worked and then it would automatically go away after a few seconds. That way, they get the notification but don't have to do anything.
# July 20, 2004 5:44 PM

Jason Mauss said:

That's not a bad idea...you could dynamically inject both the <div> into the page and the script that pops up the <div> and then makes it go away.
# July 20, 2004 5:49 PM

Johnny Hall said:

Option 3 is generally the way I go. There's usually at least some real estate on the screen that you can use.

I use the space to the right of the "action" button.

Option 4 (no message = ok) is not a good option, IMO. How many users would just click the button again and again, assuming that nothing happened?
# July 20, 2004 6:03 PM

Jerry Pisk said:

Why exactly would you redisplay the form a user has just submitted? Just ditch Asp.Net, with its incredible bad page post back model and use a real framework (Struts or Maverik) and have your business logic (saving the data) forward execution to an appropriate view - if the save is successful then forward to a page that just says "Save successful" in the body, if it fails forward the control back to the input page, with an error message.
# July 20, 2004 7:05 PM

Shannon J Hager said:

Not giving any feedback is bad. Silently succeeding looks/feels just like silently failing. If the page shows the results of the actions (if you just updated/added something and the next page shows a view of that data), then you are giving the user some feedback. If you have a form and you submit it and you still have the user on that same edit form after the add/update, then the user has no idea whether the action failed or succeeded and the only way to check is to leave the page and then come back. That's no good.

If you can not fit "Save successful" or some other verification on the page, I think you probably need to rethink your layout. Surely you would display a message if the action failed, correct? There is room, then.

If you don't need to continue the edit/viewing process, I second Jerry's suggestion above: sending to a confirmation page. I don't agree with his "real framework" troll, but that's another story...
# July 20, 2004 11:18 PM

Jerry Pisk said:

Ok, you can do it right even with .Net :) But it doesn't make it easy, the problem here is that whatever processes the request should be something else than the page that displays the input form. The input form page should only get control if it's needed, such as when there are errors in the input, or when the processing fails (so the user can try again), but not when the processing succeeds.
# July 21, 2004 1:48 AM

Memi Lavi said:

Actually, I thought about L M solution (the "toast" message) the moment I clicked the "Post" button (I guess I was inspired by SharpReader or MSN Messenger...), and I'm working on an HTC file that will perform this very same action.

Jerry - the reason we would like to redisplay the same page has nothing to do with the technology, but with the design docs. My question this time was rellevant to a J2EE project I'm involved in, but the solution will be applied to all our projects.

Shannon - Of course, in case of failure we will display error message. But the error message is displayed in a dedicated error page, with details about the required next action, and not on the same form, therefore the area problem is not rellevant.

I must say I don't like the confirmation page concept. It's, IMHO, a worse version of the popoup solution (#1, which no one mentioned as the preferrred solution). Using confirmation page we force the user not only to perform some unnecessary action (such as clicking to go to the original form) but also to go through the server when doing so (which is not a problem in the popup solution).
# July 21, 2004 2:23 AM

Jim Bolla said:

A typical page flow in one of my apps is as follows:

1: Entity List/Search - to select the entity to work with.

(clicks one - hyperlink)

2: Entity View - no action buttons, only display info and hyperlinks for edit and to add/view related entities

(clicks edit - hyperlink)

3: Entity Edit - edit form, can either modify/delete the entity record or go back to #2

(clicks save - button)

(passes validation, successful - back to page #2)

the user now knows their modification were successful because they are no longer on the edit form and they can usually see their changes on the display page. this makes sense to me because instead of focusing on confirmation, the app is focused on getting them to where they want to be next.
# July 21, 2004 10:26 AM

Memi Lavi said:

But why does the user need step #2? Why not open the form in the Edit mode?
It looks like he is forced to perform another click just to reach the task he meant to do from the start.
# July 21, 2004 11:17 AM

Jim Bolla said:

Step 2 typically has more on it than what is on the edit screen. For example, if it's a company view, then the page will not only show the data on the company record, but info like the number of employees in that company, with a link to go to the employee list for that company. Basically computed data that one couldn't modify on an edit screen and thus doesn't make sense there.
# July 22, 2004 1:13 PM

UdiDahan@TheSoftwareSimplist.com (Udi Dahan - The said:

If you are SO tapped for screen real estate that you can't afford a little green label that appears beside (or under) your action button that says "done" (or something like that) GET A BIGGER MONITOR!

Just kidding.

I suppose you could try changing the background color of the action button to green in case of success, red for failure. You could also tooltip for more information - like the reason of the failure, however most beginners haven't grasped the concept of tooltips.
# July 22, 2004 4:16 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)