[FX.php List] GET vs. POST in a web app
Bob Patin
bob at patin.com
Fri May 4 11:46:20 MDT 2007
Erik,
I have to agree with your view that we should program so that the
BACK button doesn't foul things up for end-users. Although there's
never a reason in this site to use it, I agree that it's a reflex
action for users to back out of unwanted page views (I do it all the
time), and wish I could figure out a workaround.
For this site, because my client's insistent on this, I'm going to
have to leave GETs in wherever possible, which, in my mind, is going
to make it even more confusing--sometimes the BACK button will work
for them and sometimes it won't. I tend to think that this will make
it even more confusing, because the users won't know when to back out
and when not to... but I'm not in charge, I'm just the programmer.
So here's my head-scratcher of the day: why, if FMSA only allows one
WPE connection to it, does FM Admin say "FileMaker Web Publishing
Engines" in it, and have a scrolling control that clearly implies the
ability to enter multiple WPE connections? I know I'm beating a dead
horse here, but it's just confusing to me... life should not be
confusing. All should be clear...
Oh well, I'll be up in the middle of the night moving my sites
over... no getting around it I'm afraid.
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
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
More information about the FX.php_List
mailing list