Ajax Mistakes

 

24 Jul 2007

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. I’ve compiled a list of the many mistakes developers using Ajax often make.

This list is copied from my blog post: Alex Bosworth’s Weblog: Ajax Mistakes

Disagree? Have your own mistake? This document has a collaborative page @ SWiK.net

Also check out the wiki page for places to use Ajax

Using Ajax for the sake of Ajax 6 Jun 2005

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 18 May 2005

The back button is a great feature of standard web site user interfaces. Unfortunately, the back button doesn’t mesh very well with Javascript. Keeping back button functionality is a major reason not to go with a pure Javascript web app.

Not giving immediate visual cues for clicking widgets 18 May 2005

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 loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn’t trigger the normal web UI for new page loading.

Leaving offline people behind 6 Jun 2005

As web applications push the boundaries further and further, it becomes more and more compelling to move all applications to the web. The provisioning is better, the world-wide access model is great, the maintenance and configuration is really cool, the user interface learning curve is short.

However 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.

Don’t make me wait for Ajax 6 Jun 2005

With FireFox tabs I can manage various waits at websites, and typically I only have to
wait for a page navigation. With AJAX apps combined with poor network
connectivity/bandwidth/latency I can have a really terrible time
managing an interface, because every time I do something I have to wait
for the server to return a response. God help me if it has to go to the
server’s disk before I can continue. Apps like that might even make me think Ajax wasn’t cool.

Sending sensitive information in the clear 6 Jun 2005

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. 6 Jun 2005

Ajax development is multi-platform development. Ajax code
will run on IE’s javascript engine, Rhino (Mozilla’s js engine), 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. A major obstacle in any serious
Javascript development is IE’s buggy JS implementation, although there
are tools to help with IE JS development.

Too much code makes the browser slow 18 May 2005

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 poorly coded ones, you need to have a powerful CPU to keep the functionality zippy. The CPU problem has actually been a limit on javascript functionality in the past, and just because computers have gotten faster doesn’t mean the problem has disappeared.

Not having a plan for those who do not enable or have JavaScript. 6 Jun 2005

According to the W3C 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, you’ve immediately cut a tenth of your
audience.

Inventing new UI conventions 18 May 2005

A major mistake that is easy to make with Ajax is: ‘click on this non obvious thing to drive this other non obvious result’. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that’s not in the common user experience, you increase the time and difficulty of learning your application, which is a major negative for any application.

Changing state with links (GET requests) 18 May 2005

As I’ve referenced in a previous posting, Ajax applications introduce lots of problems for users who assume GET operations don’t change state. Not only do state changing links cause problems for robots, users who are accustomed to having links drive navigation can become confused when links are used to drive application state changes.

Blinking and changing parts of the page unexpectedly 18 May 2005

The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they are pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don’t want to concentrate on harkens back to days of the html blink tag.

Not using links I can pass to friends or bookmark 18 May 2005

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.

Not cascading local changes to other parts of the page 18 May 2005

Since Ajax/Javascript gives you such specific control over page content, it’s easy to get too focused on a single area of content and miss the overall integrated picture. An example of this is the Backpackit title. If you change a Backpackit page title, they immediately replace the title, they even remember to replace the title on the right, but they don’t replace the head title tag with the new page title. With Ajax you have to think about the whole picture even with localized changes.

Asynchronously performing batch operations 18 May 2005

Sure with Ajax you can make edits to a lot of form fields happen immediately, but that can cause a lot of problems. For example if I check off a lot of check boxes that are each sent asynchronously to the server, I lose my ability to keep track of the overall state of checkbox changes and the flood of checkbox change indications will be annoying and disconcerting.

Scrolling the page and making me lose my place 18 May 2005

Another problem with popping text into a running page is that it can effect the page scroll. I may be happily reading an article or paging through a long list, and an asynchronous javascript request will decide to cut out a paragraph way above where I’m reading, cutting my reading flow off. This is obviously annoying and it wastes my time trying to figure out my place.

Blocking Spidering 6 Jun 2005

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.