What AJAX Should Not Be

Continuing on the AJAX theme, I have a couple ideas about what AJAX should not be:

AJAX should not be hard to debug.
The moment I see a developer machine with a packet sniffer in one window and a script debugger in a second window, I know it’s time to fire up Microsoft Project and make some adjustments. A good AJAX implementation will have tracing, logging, and diagnostics built-in.

AJAX should not be hard to test.
Automation == good.
Room full of interned monkeys clicking randomly == bad

AJAX should not be SmartNavigation 2.0
SmartNavigation (obsolete in 2.0) uses a clever trick to make a web application feel like a windows forms application. By POSTing from a hidden IFRAME, the end user doesn’t experience the typical flash and loss of scroll position during post back. Unfortunately, SmartNav only works for trivial web applications. People sink a good deal of time trying to get SmartNav to work before giving up.

If you think about it, AJAX and SmartNavigation have similar goals (and by manipulating the DOM with async results, an eerily similar implementation) - I just hope whatever AJAX becomes turns out better.

P.S. The SetFocus and MaintainScrollPositionOnPostBack members of the Page class in 2.0 will do most of what you wanted to do with SmartNav in 1.x.

AJAX should not confuse the user. Those little animated icons in a web browser are a great way to tell the user: “Thank you for choosing the Internet. Please stay on hold and a server will respond to your request shortly. This request may be monitored for quality purposes. (cue soft jazz by Albert, Herb). Every AJAX design should plan to give visual feedback when processing is underway. AJAX toolkits should make this easy.

Also, AJAX should never annoy the user. There is a good potential of AJAX being the next <blink> tag.