Cart
[Home] [By Thread] [By Date] [Recent Entries]
> AJAX is changing things. A typical AJAX page cannot be easily searched > or indexed. The programmatic nature of the page prohibits this unless > the search engine is going to try executing the javascript to get the > final page. > > Even worse is that the pages often can't be printed so the browser may > be able to display the page, but it's internal model is inadequate for > repeated representation and hence printing. Scary. The concept of page is outdated and innapropiate for AJAX applications. Think about a ajax web chat. Or a ajax web point of sale. Its dificult to define "page" here because.. well.. theres not page, or theres only 1 page. Even the desktop concept of "form window" is blurry on web ajax applications because the flexibility able to mix interface ares wildly. Imho, for pages you can hardly index, you need a "shadow". For flash pages you use the meta content. Because a browser can past the intro page, a well formated informative intro page is enough for browsers. Ajax applications use state machines. Is not a page but a state. > Another thing, people always complain about the back button breaking, > and if an ajax application or toolkit fixes this back-button breakage > it is lauded as being very well thought out. I'm tired of it, I'd like > ones that didn't break either the forward or back button. That would > a better application. Or one that worked with all my bookmarklets and > browser plugins. Hmm I guess that will never happen. I am starting to > think that Ajax has very quickly overshot the mark of what makes the > technique useful, into what makes it harmful, and in about another 3-4 > months everyone is going to be complaining. The history buttons is designed for non-dynamic websites. On a dynamic website the concept "back" can be wrong. Think about a website shop with credit card payment. Can you go back and undo a payment?. You can do back, and often break poorly coded sites. Its a problem. The way the history work, Is something the browser manage, and is somewhat unknow or readonly to the application. But a application need a readwrite history, and able to overload events on the back/forward buttons. Because the actual design forbid the webpage to control back/forward.. we are stuck on a usability problem. I dont see a solution here. Of course, we can still code to detect the user returning with the back button, then avoid resending INSERT INTO, and other non-repeteable actions. But the original problem is not fixed, so will attack elsewhere.. on AJAX apps where "back" is even harder to code. Example: often you can fuzzy Gmail with the back button on the Epiphany webbrowser :D
|
