Posted
by
Zonk
on Thursday June 08, 2006 @03:36PM
from the goin-back-in-time dept.

IdaAshley writes "A major challenge of Asynchronous JavaScript and XML (Ajax)-driven Web sites is the lack of a Back button. Mike Brittain discusses ways to get around this obstacle in part 1 of the 'Developing PHP the Ajax way' series." From the article: "The Web is a page-by-page medium. The backward and forward buttons on your browser's toolbar direct the browser from page to page. When Macromedia's Flash became all of the rage, developers and users started to see how Rich Internet Applications (RIAs) break this metaphor. You might click around a few sites, land on a Flash-based Web site, then click around in it for a few minutes. One click of the Back button and the ride is over. Rather than going one step backward within the Flash site, you completely lose your place."

This is terrible, and does nothing to make the back button in the browser work. At best, it gives you an undo/redo in the applications. The back button not working is more of a symptom than the actual problem, and if widely implemented this kind of workaround is only going to distract and make it less likely that the actual problem get fixed.

Not only does the hidden frame + named anchors work with AJAX, it also works for other browser-button-challenged technologies, like full flash sites. Case in point, one of the better known design studios (apparently does work for Ford, Motorola, AOL, Disney, Bacardi, etc) just relaunched, so click click click for working browser buttons [2advanced.com].

Doesn't work all that well. I navigated the site a bit and forgot all about why I was there because it's so pretty... then I remembered, tried the back and forward buttons and the problems started. Blank pages, pages with just the pretty background image and no menu/content. Inconsistencies when going back and forth multiple times. Finally I was stuck in black page mode. Music played throughout though.

All it does is create a history stack then store it as a cookie. The history is then used to power the back button in whatever the application is.

What'll intrigue me is when someone comes up with a way to integrate the back functions of ajax and friendsto work seamlessly with the browser back button. Hmm... someone should do a Firefox extension.

My thought would be to set the index page up to read that history stack cookie and redirect the browser to a live page. That way, if the user hit's the back button, they get kicked back to the index page. The index page slices the top item off the stack and redirects the user to the live page with the top item on the history stack as the target.

Not a FF plug in, but it would be a seamless solution to the back button issue for a website.

There's nothing magical about making the back and forward buttons work alonsgide AJAX. The way Google does it is to track a uniqke token that associates what your page state is on th ebackend, and pass the token along in an IFRAME every time you do something on the page. Since an IFRAME will work along withh your back/forward buttons, functionality is preserved.

It isn't rocket science. Sites who don't want to do this properly are either designed by people who don't know any better, are lazy, or some combination of the two.

It depends entirely on which browser you are in as to whether it works in Gmail - IE and Firefox take you back to the previous page as expected, but Safari reloads Gmail totally (the back button takes you to the redirect page that is part of Gmails loading system).

I'm using Firefox 1.5.0.4 as well. I have the default security settings enabled. Sometimes when I hit the back button in GMail it works, but usually, I get the following message after a 30 second delay:

Loading...

This seems to be taking longer than usual. Your session may have been interrupted. If your account doesn't appear in the next few seconds, please refresh this page in your browser.

If you continue to have trouble loading your account, please visit the help center [google.com] for troubleshooting info

When you browse Google Maps for example, there is a button called "Link to this page". It's needed because the URL in the address bar doesn't actually allow you to browse to the map you are viewing. This is because google has no way of dynamically specifying the "link" URL in your address bar without making your browser go to another page.(Like when you change location.url -- it makes your browser actually go there, not just display different text in the address bar.)

As other people have pointed out in other threads you can have working bookmarks without changing the window.location, using anchors [contentwithstyle.co.uk]. The site in my sig [coralbark.net] uses a primitive implementation but still needs a lot of work.

We already know that Morfik and GWT support all of these features, but does Script# or Atlas, yet? I didn't think so, but my memory may be faulty.
Even more importantly than knowing how to support is not having to know how to support it. Thankfully AJAX is advancing so quickly that articles like this are going to be less and less relevant since more and more tools will just implement the features right out of the box.

I'm 99.5% positive that Adobe Flex can help address using back/forward buttons in the browser and Google has code to do this with Ajax. If I'm not mistaken, Gmail no longer croaks if you try using back/forward now. I'm at work and don't want to take the time to look up the links, so (hopefully) free mod points to whoever feels like posting some links to this stuff!!

That being said, the article is garbage. People ARE integrating it into the browser controls... no point in using this crappy method. Fact is, most users will, through force of habit, use the back/forward buttons, or mouse gestures, or keyboard shortcuts.

This doesn't talk about using the browser's native back/forward buttons, as I inferred from the summary. It just creates fake back/forward buttons within the application, and maintains a history stack. Move along, nothing to see here...

A major challenge of Asynchronous JavaScript and XML (Ajax)-driven Web sites is the lack of a Back button

So says you. I say: if it makes sense for a user to hit your back button, why are you using Ajax? Do users hit their back button when they're using native desktop applications? Sounds to me like you're just to ajax-ify a traditional web application for the heluvit.

The map example is always the gray area, and I'll admit that it does make some amount of sense (however, somehow desktop map applications seem to pull it off without a back button). Other than maps, though, are there any other examples?

I don't track too many AJAXy sites, but I should think anything where you can have a significantchange in scope of the content presented (particularly when it makes up the bulk of the page andthere is little else in the way of controls or context) ought to allow the user to go back to aprevious scope. Mail box to mail box, browsing a nested discussion.

We implemented in-page history (and bookmarking) in Vox [vox.com] by overloading the anchor portion of the URI (the part after the #) and using iframes in IE. The anchor URI form is in simple key:value form that the JavaScript parses and triggers an event to enter the state specified.

Dojo has already solved [dojotoolkit.org] this and is also an all-around great ajax toolkit. It's major drawback is a horrible gap in documentation. If you're not afraid of mailing lists and IRC, this is easily overcome.

PHP is a lost cause... please google for "Ruby on Rails". You'll find no bullshit coders there.

Ok, I'll bite...

PHP is not a lost cause precisely because of your last sentence - what people love about PHP is that you can do whatever you like, armed with nothing more than a few HTML tags, whether or not you have a clue what the implications are, whether or not you can spell "security hole", whether or not there is any prospect of your code being maintained, even by the original coder, a week after it has

I don't doubt that Scheme at least is a wonderful language (although personally I prefer zetalisp). But how many libraries are there for, say, manipulating PDF, driving graphics packages or doing cryptography? Any coder who is reinventing every single wheel from scratch isn't a real coder. And how well does Scheme scale for web apps? How much native support does it have from

I 'use' (am abused by) WebCT Vista for my university studies. And it is crap.

When using a web browser you would expect that the standard functions to work, back and forward buttons, multiple tabs on a site and so on. But WebCT Vista doesn't let you do that! Oh no, it restricts you to one page and the navigation is terrible.

People already know how to use webpages, they do not need a new concept thrust at them, especially not a new concept that breaks the old.

I think that Yahoo mail works really well, it is an example of an online app that works with in the web browser concept and offers interaction beyond that for those who want to learn.

Look, the browser is still a two-dimensional (I guess two and a half, if you count pop-ups) document navigation application. If Ajax and other schemes, by their very nature, break out of this linear document structure without the cooperation of the browser itself, then that's what you get.I'm not dissing Ajax - I'm just saying it's best used in certain circumstances. The times when you don't WANT the user to have arbitrary control over navigation - such as a shopping cart checkout or CMS tools, in which t

Back in a shopping cart should always be a contextual "cancel" -- if you're on the page asking for final authorization, its the same as "no". If you're on the page showing you the items you have ordered, its the same as "go back to shopping". Forward should always be the same as hitting the submit button -- forward on the "whats your address" form should process the form if it is sufficiently filled in or throw an error if it isn't. Forward on final authorization should get you "Thank you for this order!

Ok, lets think about this one a little bit. I have no patience for toolkits and perfer to write my own code, and Im sure that there are other folks who want to figgure this one out and not just whimp out and borrow code from google.

On Entering the page:
1) check the url for a hash that would say which subsection if it exists load that section
(this resolves the problem of bookmarks, as the string after the hash will identify the specific section)
2) if there is no hash in the url, check