[FX.php List] GET vs. POST in a web app
Bob Patin
bob at patin.com
Fri May 4 12:46:16 MDT 2007
Dale,
Your move to Ajax sounds like an excellent plan for me...
I just changed the site to put GETs everywhere that I could, per my
client's instruction--against all of my cautions.
My biggest concern, and I told him this, was that by allowing the
BACK button in some instances and not in others, will encourage their
users to try the BACK button everywhere--which I'm certain they'll
do. However, there's no getting around the need for POSTs when users
are editing records, especially containing sensitive information, or
adding long blocks of text, which they'll do on this site.
But the customer's always right. :)
I agree too on the non-linear method; in general, I do that too; even
in carts, I make it possible for users to go anywhere at any time,
although I make it easy for them to follow the checkout path, since
that's what most users expect to see. I particularly like checkouts
where it's easy to find the checkout button and follow the logical
steps to finish the transaction; I'm always annoyed when I have to
search for the checkout button, and then search for the next button
in the process... bad interface design.
Bob
> 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
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
More information about the FX.php_List
mailing list