[FX.php List] GET vs. POST in a web app

[Kevin Futter]

On 5/5/07 3:30 AM, "Erik Andreas Cayré" <erik at cayre.dk> wrote:

> 
> Den 04/05/2007 kl. 18.33 skrev Dale Bengston:
> 
>> Read all the way to the end this time. ;-)
>> 
>> I would work on navigation that reduces or eliminates the use of
>> the browser back button. I have one client with two of my sites and
>> https, and pressing the back button (IE Windows) gives the POST
>> warning followed by a blank page. Yuck! I spent a lot of time
>> working on the interface to eliminate that habit. Also, I had some
>> "cancel" buttons that used history.go(-1), which is pretty much the
>> same thing.
>> 
>> If you have alternatives in your interface, then you have
>> ammunition to say, "Don't use the back button. Use the site
>> navigation."
> 
> I feel compelled to quote Jakob Nielsen (renowned usability expert):
> 
> The following quote is from "The Top Ten Web Design Mistakes of
> 1999", which can be read in full here http://www.useit.com/alertbox/
> 990530.html
> 
>> 1. Breaking or Slowing Down the Back Button
>> The Back button is the lifeline of the Web user and the second-most
>> used navigation feature (after following hypertext links). Users
>> happily know that they can try anything on the Web and always be
>> saved by a click or two on Back to return them to familiar territory.
>> 
>> Except, of course, for those sites that break Back by committing
>> one of these design sins:
>> 
>>     * opening a new browser window (see mistake #2)
>>     * using an immediate redirect: every time the user clicks Back,
>> the browser returns to a page that bounces the user forward to the
>> undesired location
>>     * prevents caching such that the Back navigation requires a
>> fresh trip to the server; all hypertext navigation should be sub-
>> second and this goes double for backtracking
> 
> I completely agree with Mr. Nielsen. The browser's back button is a
> very important and beloved UI widget, as seen by the user.
> Since we are building for "the user", I personally would not ask the
> user to break his/her habits when using my site.
> I strongly believe that leaning on the user's experience and well-
> established habits, is right on the track to success.
> 
> That said, building a site which handles the users' backtracking
> elegantly isn't easy, and I certainly don't have the 'right' recipe
> fro this.
> Googleing around turnd up:
> -a very good article by Tony Marston (I think he is very competent):
> http://www.tonymarston.net/php-mysql/backbuttonblues.html
> -ugly but with good suggestions: http://
> www.planetsaturn.pwp.blueyonder.co.uk/backbutton/
> -short but authoritative(?): http://www.w3.org/Provider/Style/Input.html
> 
> And to Dale: I don't really disagree with what you wrote. My point is
> that websites should be built so that they don't fail (even
> gracefully) if the user chooses to use the back button. Of course,
> designing so that the user isn't even tempted to use the back button
> is even better!
> 
> /Erik

I can only reinforce what Erik has said here about the back button. I
certainly agree that using GET instead of POST is suicide, but there's no
need to reinvent the navigational wheel, and the back button is a staple for
for users at all levels, but most especially at the lower end of the
browsing food chain.

-- 
Kevin Futter
Webmaster, St. Bernard's College
http://www.sbc.melb.catholic.edu.au/


#####################################################################################
This e-mail message has been scanned for Viruses and Content and cleared 
by MailMarshal
#####################################################################################

This e-mail and any attachments may be confidential. You must not disclose or use the information in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. The College does not guarantee that this e-mail is virus or error free.  The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College.