Thursday, April 19, 2007

Rethinking the back buton

Rethinking the back button problem

There are a host of problems when dealing with web browsers that implement a corporate intranet application and not just browsing static content or simple applications like blogs. Here are some typical problems:

- Double clicking and submitting several times the same form.
- Using the back button once or several times and then the user resubmits the form with a warning from the browser.
- Using the back button and then clicking on a link. The link relied on information stored in the user session on the server which is no longer there.
- The refresh button or F5 problem.
- The several navigator windows problem. (Ctrl-n)

There are different ways of solving these problems some more elegant than others. For example a typical way of dealing with the back button is by expiring the page. This works but is not very user friendly. The user ends up either going back again or forward and gets lost quickly.

Another way is to eliminate the back and forward buttons altogether by putting the entire application in another window without the menu items and then providing “internal” back buttons. Well putting an application in another window is clunky; what do you do with the original window? Also the user can always use the backspace and F5 buttons.

A secure and surefire way of dealing with back, refresh, and double clicks is with a synchronizing token. Each form has a unique generated token from the server and only a submission with the same token is allowed. Once a token has been used it cannot be reused. This works real well, but the user is left with a page saying that operation has already been treated. Where does the user go now? It’s not elegant.

Most of these strategies revolve around suppressing the use of these buttons. But there is a possibly a better way! In several of my recent projects instead of restricting things I’ve actually embraced the use of these buttons. Yes it sounds frightening but in the end the users are happier because the browser behaves like the rest of the web and thus there are less user experience problems.

Here’s the basic strategy:

1. Stop double clicks on action buttons with a simple javascript
2. Let users repost if they want to, no token. This could even be a feature. Create 10 things really fast. Submit, back, submit, back, etc.
3. All other links (requests) should contain the entire context in the URL. If context is too big use class serialization and then compression and then post instead of get. This actually works.
4. Redirect on the client and not on the server after creation, modification, or deletion. This eliminates the refresh problem.
5. For things that you really don’t want to resubmit use a token. From a business perspective there might not be that many.

I can write howtos if anyone is interested. Just leave me a comment.

3 Comments:

Blogger Jean-Baptiste said...

Hi Lee,
in fact most Java frameworks suck ;)

The really elegant solution to this problem is to use a continuation based web framework, like Seaside.

Yes, Smalltalk is outdated, but this is the way to solve the problem, in principle...

[1] http://www.seaside.st/
[2] http://rifers.org/wiki/display/RIFE/Web+continuations

3:28 PM  
Anonymous Anonymous said...

I suppose you've moved much past this issue by now, but I like the suggestions you mentioned. Is there any chance of posting some how-to's like you mentioned?

7:40 AM  
Anonymous Anonymous said...

I supposed you've moved well past this already, but I was wondering if it were possible to share some how-to's as you mentioned at the end of your post.

Shadi
calgaryshadi at hotmail dot com

7:42 AM  

Post a Comment

<< Home