[
Lists Home |
Date Index |
Thread Index
]
> 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
|
