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 Ajax isn’t seriously needed to improve usability but rather experiments in what Ajax can do or trying to fit Ajax somewhere where it isn’t needed.
Breaking the back button
Keep in mind however that good web design provides the user with everything they would need to successfully navigate your site, and never relies on web browser controls.
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 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
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
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. However, remember that the ‘A’ in AJAX stands for ‘Asynchronous’, and the interaction can be designed so that the user is not prevented from continuing to work on the page while the earlier request is processed.
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 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.
Forgetting that multiple people might be using the same application at the same time
In the case of developing an Intranet type web application, you have to remember that you might have more than one person using the application at once. If the data that is being displayed is dynamically stored in a database, make sure it doesn’t go “stale” on you.
Too much code makes the browser slow
Blinking and changing parts of the page unexpectedly
The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they 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. “Yellow Fade”, “One Second Spotlight” and other similar techniques are used to indicate page changes unobtrusively.
Not using links I can pass to friends or bookmark
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.
Asynchronously performing batch operations
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
Inventing new UI conventions
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 it’s not in the common user experience, you increase the time and difficulty of learning the application, which is a major negative for any application. On the plus side, intuitiveness is a function of learning, and AJAX is popularising many new conventions which will become intuitive as time goes by. The net result will be greater productivity once the industry gets over the intuitiveness hump.
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.
Not cascading local changes to other parts of the page
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 impressively 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.
Mimicing browser page navigation behavior imperfectly