Ajax: It's About the User

Most programmers design for programmers or most programmers program forthemselves. Call it laziness, call it self-serving, most programmers will develop as it suits them. This form of development is not always what suits the end user from a usability point of view. Most often the final product is a result of the least amount of programming or the simplest design pattern.

The Ajax name was first mentioned by Jesse James Garret from Adaptive Path in Ajax: A New Approach to Web Applications in which Jesse explained that Ajax is a new methodology to building web applications by leveraging dynamic browser display technologies including CSS, DOM and JavaScript, specifically the XMLHttpRequest object. These technologies have been with us for a while but the power of such technologies has remained under the radar until Google introduced Google Suggest and Google Maps recently.

Since then several Ajax posts have been made by bloggers either denouncing it for it's disruptive affect on well respected design patterns or brainstorming on techniques to harness it's power.

The Ajax concept is not a replacement for the traditional model of web browsing. Too often we have seen developers design for themselves with previous web technologies and as a result producing harmful interface reprocutions such as breaking the back button with frames and Flash because it suited their definition of an enhanced "user experience". Ajax can shine through enhancement of page components by minimizing on full data updates and screen redraws when most of the page remains consistent. It can also enhance the interface controls and add drag and drop capabilities. These additions are not so harsh as to confuse the user into thinking that the interface has changed pages. In both of the Google examples the enhancements clearing improve the application without the user being confused by the page state.

"But users shouldn't be using the web for applications" some say. Wrong. Users will use what they deem fit. Millions of people don't use web based email systems because there is no alternative. They use these services because they are compelling. A more compelling experience than the alternative desktop or downloadable option. Java applets had their time but incompatibilities and slow download and initialization times make it extremely frustrating and difficult for users to adopt and accept applets.

Testing and architecture can be modeled to a better interface. By enhancing existing tools we can provide a suitable development and testing environment while simultaneously providing an experience that the user wants. Let's not make our laziness hurt the user experience.