Ajax Back, Forward, Reload and PHP
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
That has been discussed to death and known for years. You do it with a hidden iframe and anchor links (#blahblah). That's the gut of the whole deal.
I felt the same way. I recommend you install the Stylish firefox extension and specify the following CSS modifications (also removes left hand nav bar):
@-moz-document domain(slashdot.org) {
body {
font: 82%/150% Times !important;
}
#contents { margin-left: 0em !important;}
div#links{display:none !important;}
}
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.
The hardest part would be deciding on a standard API for this.
If this signature is witty enough, maybe somebody will like me.
How about doing something that actually uses the built-in back and forward buttons of the browser (when possible)?
Like something similar to this?
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.
Friends help you move. Real friends help you move bodies.
Never forget: 2 + 2 = 5 for extremely large values of 2.
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.
As other people have pointed out in other threads you can have working bookmarks without changing the window.location, using anchors. The site in my sig uses a primitive implementation but still needs a lot of work.
Struggling to find a day everyone can make? WhenShallWe.com
Ever use GMail? Next time you're ina folder hit your back button.
Guess what? Works as expected.
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.
No, C. Most people think it was named after C. Everett Koop, but they're mistaken.
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.
Mooniacs for iOS and Android
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.
I wank in the shower.
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 they must be locked into a certain workflow for the sake of application structure, security, user hand-holding, or speed. Ajax is great for db-driven tools, especially when trying to get the speed and interactivity of a client application, plus greater control over navigation to avoid repeat POSTs, etc.
I can appreciate that everyone is trying to innovate a way around this problem, and it seems there are some possible solutions with compromises - that's what makes new waves of tech like Ajax come into existence in the first place. But sometimes you just have to remember there's a time and a place for a certain tool.