Ajax: My Pet Peeves
When looking at applications out there right now, I feel like they are missing/forgetting some things that hurt the user experience. These things may not be visible to the user, but you can tell when or when they are not there.
#1 - Not coding for the refresh/back/forward actions
The first thing is not taking care of the refresh/back/forward actions Now this is one of the major things that we deal with in applications that have always given us headaches. I talked about a solution here and there is another solution here. Both solutions give us, the developer, a chance to make the user interactions more seamless.
#2 - Not caching on client
The second thing is not caching data on the client. Now most developers will cache data on the server so we are not pounding the SQL database or other objects to obtain the same dataset over and over. We do not need to get the data for a dropdown list more than once if the data does not change every second. Now this same principle applies to the client side. We do not need to keep getting the data over and over again for the same requests.
One example of this is a linked select better known as double or triple combo elements. If we have a user that can not make up their mind if they have a problem with their computer or brain, they will keep selecting the options from the lists. Each time they make a request the server is called to get the data. If you implement caching by holding this info in arrays and objects, we can use this instead of calling the server for the same data over and over again. Plus this means the fields will be filled in in fewer time span.
#3 - Doing too much
For me Ajax is meant to make the user experience work better. Limit post backs, maintain state, eliminate errors, and so on. Implementing too much Ajax on an application may cause the user more headaches than it is worth. One example of a bad use of Ajax is a person is making a "Ajaxish framed site" (I made up the term and it sounds bad!) Instead of the user navigating to other pages to get information, the developer was using Ajax to pull in the data. This is not benefiting the user at all since nothing is happening other than changing the data. This is causing issues with bookmarking the page and so forth. Not a good design.
#4 - Forgetting that localhost != real world
It is impossible for a user in England to have the same response time as a user in the USA when the server is sitting in the USA. It takes time for data to go through the tube. When working on local host it will be fast! Think of me at home sitting on a dial-up connection versus me at work on a T1 line. Who will win that race? If you want the localhost to act more like a real connection introduce some random latency into the code for testing. Add some "sleep" or pauses into the code. It will make you realize how slow it can be for a user on the other side of the world.
#5 - GET still has a length limit
I seen some applications using GET to send back information to the server. The URL is still limited by IE's 2,083 characters. Mozilla and Firefox have a larger limit and I think Opera is even higher, but you are limited to IE's trouble. So if you are sending large data via GET, you may want to change it to POST.
#6 - Forgetting basic user interface design
I see that people forget the basics of user interface design with Ajax applications. If you make a request, give the person a visual clue. If you have a link, make it look like a link. People do not know they need to drag this there or click here while spinning the mouse 360 degrees. Every Web page has a basic navigation people are used to. Do not recreate the wheel if the basic concept does not make sense at first glance!
Well I am sure I could come up with more!
Eric Pascarello