Wednesday, April 12, 2006

AJAX Mistakes

Ajax is an awesome technology that is driving a new generation of web apps. But Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as well as server side state problems and server load problems.

This's a list of the many mistakes developers using Ajax often make:

Using Ajax for the sake of Ajax
Sure Ajax is cool, and developers love to play with cool technology, but Ajax is a tool not a toy. A lot of the new Ajax applications are really just little toys, not developed for any real purpose, just experiments in what Ajax can do or trying to fit Ajax somewhere where it isn’t needed. Toys might be fun for a little while, but toys are not useful applications..

Breaking the back button
The back button is a great feature of the standard web site user interface. Unfortunately, the back button doesn’t mesh very well with Javascript..

Not giving immediate visual cues for clicking widgets
If something I’m clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading..

Leaving offline people behind
With this new breed of Ajax applications, people who have spotty internet connections or people who just don’t want to switch to the web need to be accomodated as well. Just because technology ‘advances’ doesn’t mean that people are ready and willing to go with it. Web application design should at least consider offline access. With GMail it’s POP, Backpackit has SMS integration. In the Enterprise, it’s web-services..

Sending sensitive information in the clear
The security of AJAX applications is subject to the same rules as any web application, except that once you can talk asynchronously to the server, you may tend to write code that is a very chatty in a potentially insecure way. All traffic must be vetted to make sure security is not compromised..

Assuming AJAX development is single platform development
Ajax development is multi-platform development. Ajax code will run on IE’s javascript engine, Spidermonkey (Mozilla’s js engine), Rhino (a Java js implementation, also from Mozilla), or other minor engines that may grow into major engines. So it’s not enough just to code to JavaScript standards, there needs to be real-world thorough testing as well..

Too much code makes the browser slow
Ajax introduces a way to make much more interesting javascript applications, unfortunately interesting often means more code running. More code running means more work for the browser, which means that for some javascript intensive websites, especially inefficiently coded ones, you need to have a powerful CPU to keep the functionality zippy..

Not having a plan for those who do not enable or have JavaScript
According to the W3 schools browser usage statistics, which if anything are skewed towards advanced browsers, 11% of all visitors don’t have JavaScript. So if your web application is wholly dependent on JavaScript, it would seem that you have potentially cut near 10% of your audience..

Not using links I can pass to friends or bookmark
Another great feature of websites is that I can pass URLs to other people and they can see the same thing that I’m seeing. I can also bookmark an index into my site navigation and come back to it later. Javascript, and thus Ajax applications, can cause huge problems for this model of use. Since the Javascript is dynamically generating the page instead of the server, the URL is cut out of the loop and can no longer be used as an index into navigation. This is a very unfortunate feature to lose, many Ajax webapps thoughtfully include specially constructed permalinks for this exact reason..

Inventing new UI conventions
Using complex logic in the page design such as ‘click on this non obvious thing to drive this other non obvious result’ will increase the time and difficulty of learning the aplication, which is a major negative for any application..

Blocking Spidering
Ajax applications that load large amounts of text without a reload can cause a big problem for search engines. This goes back to the URL problem. If users can come in through search engines, the text of the application needs to be somewhat static so that the spiders can read it..

Character Sets
One big problem with using AJAX is the lack of support for character sets. You should always set the content character set on the server-side as well as encoding any data sent by Javascript. Use ISO-8859-1 if you use plain english, or UTF-8 if you use special characters, like æ, ø and å (danish special characters) Note: it is usually a good idea to go with utf-8 nowadays as it supports many languages)..

Changing state with links (GET requests)
The majority of Ajax applications tend to just use the GET method when working with AJAX. However, the W3C standards state that GET should only be used for retrieving data, and POST should only be used for setting data. Although there might be no noticable difference to the end user, these standards should still be followed to avoid problems with robots or programs such as Google Web Accelerator..

Problem reporting
In a traditional server-side application, you have visibility into every exception, you can log all interesting events and benchmarks, and you can even record and view (if you wish) the actual HTML that the browser is rendering. With client-side applications, you may have no idea that something has gone wrong if you don’t know how to code correctly and log exceptions from the remotely called pages to your database..

Return on Investment
Sometimes AJAX can impressibly improve the usability of an application (a great example is the star-rating feedback on Netflix), but more often you see examples of expensive rich-client applications that were no better than the plain HTML versions..

<.adjuster />

1 comment:

  1. I agree with you, AJAX is a powerful technology if its used wrong it could be a disaster but if its used right it is very useful, example of that is 37signals products.

    As it adds more complexity to web pages or in another explanation it turns web pages to web apps, it needs more accurate User Experience design.

    The first goal of any web app should be User Experience and the user experience designer is the one who should decide wether to use this technology here in this specific way or not, depending on weather the user will like it and will be able to understand it and use it or not.

    And about breaking the "back" button you are true but the most popular thing that always break it is the new windowed links <a target="blank"> that is not valid to strict Doctypes but valid to Transitional DTD's, and that you use right here in your side bar :)