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

Erik Andreas Cayré erik at cayre.dk
Fri May 4 11:30:17 MDT 2007


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

> Dale
>
> On May 4, 2007, at 11:10 AM, Bob Patin wrote:
>
>> I'm finishing up a large project for a client whose users will be  
>> a group of hospitals and physicians. The whole project is  
>> finished--or should I say, it WAS finished--until the end client  
>> (a hospital person) noticed that using the BACK button caused the  
>> POST warning to come up, since so many pages were displaying the  
>> results of various POSTs.
>>
>> So my client asked me if I could go through the site and replace  
>> all the POSTs with GETs. I cautioned him, pointing out the fact  
>> that everything would be in the clear, including passwords, but he  
>> asked me to go forward with the change anyway.
>>
>> So I did so... and immediately saw that logins didn't work because  
>> the @ sign in emails would break the URL in a GET. I then saw that  
>> editing a user's profile, which contained email addresses, as well  
>> as possible URLs, would also not work using GETs.
>>
>> So to have an answer ready for them, here's my question: is there  
>> a way, using a GET command, to make it work with @ signs and  
>> various other special symbols that URLs use? I don't want to go  
>> down this road, but I'm anticipating their insistence on trying to  
>> make this work.
>>
>> Before you tell me, I know and agree that using GETs like this is  
>> an awful idea, but the client (the end-user) is concerned about  
>> how the BACK button causes problems. How do you guys get around  
>> this, or do you?
>>
>> Thanks,
>>
>> Bob Patin
>> Longterm Solutions
>> bob at longtermsolutions.com
>> 615-333-6858
>> http://www.longtermsolutions.com
>>
>>   CONTACT US VIA INSTANT MESSAGING:
>>      AIM or iChat: longterm1954
>>      Yahoo: longterm_solutions
>>      MSN: tech at longtermsolutions.com
>>      ICQ: 159333060
>>
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list



---
Erik Andreas Cayré
Spangsbjerg Møllevej 169
6705 Esbjerg Ø

Privat Tel: 75150512
Mobil: 40161183

---
»Interesse kan skabe læring på en skala sammenlignet med frygt, som  
en nuklear eksplosion i forhold til en kineser.«
--Stanley Kubrick

»Kun p....sure mennesker kan ændre verden. Innovation skabes ikke af  
'markedsanalyse', men af folk, der er afsindigt irriterede over  
tingenes tilstand «
--Tom Peters

»Hvis du ikke kan forklare det simpelt, forstår  du det ikke godt nok.«
-- Albert Einstein

»Hvis du ikke har tid til at gøre det rigtigt, hvornår vil du så have  
tid til at lave det om?«
-- John Wooden, basketball coach




More information about the FX.php_List mailing list