Lists Home |
Date Index |
> AJAX is changing things. A typical AJAX page cannot be easily searched
> or indexed. The programmatic nature of the page prohibits this unless
> 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
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