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

Fri May 4 12:33:15 MDT 2007

Hi Erik,

I completely understand where you're coming from. I would also agree  
wholeheartedly that users need a back button "lifeline" in situations  
where it's not clear what to do next, or if they've made a wrong  
choice. There should be no penalty for the latter; the former infers  
a need for better interface design. I would also never try to disable  
the back button or hijack its function. (I'm not sure you can even do  
this.)

In my case, the drive to navigate around the back button came from IE  
Win and SSL breaking it. This was a scenario I could only repeat on  
the live server with SSL. If I ran it in my testing environment, or  
bypassed SSL on the live server, it worked fine.

One way I minimize the problems created by using the back button (if  
it works!) is to avoid sending the user down a linear path of several  
screens towards a goal. I always use a hub, and allow the user to  
edit some part of the workflow and return to the hub. That way they  
can see progress as they build up the order, or proposal or  
application or whatever it is they're working on. Also, it means I  
don't have to force what order they will edit sections; they can do  
it in any order they want. And they can review progress all the way  
along.

In this scenario, the back button only moves you from the hub back to  
the last piece being edited, or from the edit screen back to the hub.  
So one can't get into too much trouble there.

In the past year, I've begun switching to an AJAX model for modifying  
records, so the screen doesn't even change. Just pieces of it as the  
user's input is accepted.

Dale

On May 4, 2007, at 12:30 PM, Erik Andreas Cayré 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
>
>> 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
>
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list