Article: AJAX and SaaS
by Asif Nawaz. Published on January 27, 2009.
As a business that has a central focus on developing web-based applications, we're seldom confronted with the need and requests to use AJAX throughout user interface development to replicate the experience of a deskptop application. Whilst I am a fan of replicating the speed and durability (if you can call it that) of a deskptop application, I genuinely believe that the excessive use of AJAX to replicate a desktop experience in a browser based application is, simply put, overkill. You'll see this belief passed on to any in-house applications that we have developed, be it Plum CMS or Vesica.
Users are generally used to dealing with websites a certain way in a browser; they generally use the back button, they're used to seeing the page load when they press a link or hit the submit button, and they like to see what's happening with their submission or clicks (which is sometimes difficult to explain with AJAX). Accomplishing all of the above is a little tricky with AJAX and in many instances, it takes producing three times the amount of code to accomplish a simple task; perhaps more if the code is written well and error handling is built into it.
I have failed to understand why so many developers and development companies excessively use AJAX to simply ruin the user experience by way of AJAX being cool. Being cool doesn't accomplish the business purpose, and when developing an application or a piece of software, the business purpose is the entire case for spending time or money on building something at all. It's a different argument if the application is being built in flash using actionscript; within a flash interface the masses are used to different kind of functionality.
During some of the GUI development of Vesica, we tried building the entire program interface using just AJAX. It got our development team really excited and we got to polish up our AJAX skills, but from a usability standpoint, we had great difficulty in explaining the use of AJAX. We, therefore, went back to a combination of AJAX and simple web page processing. Although we are still debating using AJAX on some parts of the software, ultimately, the decision for anyone to deploy AJAX in an SaaS model should be driven by:
- Any value it will add to the overall appearance of the software
- Any functional value in terms of ease of use or saving time
- The need to populate lists and menus without refreshing the whole page
- The need to manage systems resources and pass on some of the data load to a client machine
There's a whole lot more that can be done to mitigate what goes wrong in a typical user experience with the use of AJAX, but that's another topic for discussion: "Guding the User" - coming soon to a Tech Talk issue this year.
