[FX.php List] GET vs. POST in a web app
Dale Bengston
dbengston at preservationstudio.com
Fri May 4 12:37:07 MDT 2007
It says "FileMaker Web Publishing Engines" because FMI planned (and
maybe plans) to allow that to happen. Since it is not currently
possible, I question why the interface for FMSA still includes it,
along with a portal that could show many WPEs. Is this some
subversive statement by the QC department that it *should* be
allowed, so it got left in?
My point, I guess, is it's clearly misleading and confusing. If the
software only allows one, then it should manage our expectations better.
Dale
On May 4, 2007, at 12:46 PM, Bob Patin wrote:
> 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
>
> _______________________________________________
> 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