How safe are hidden AJAX requests that fake performance?

What is a hidden AJAX request?

I’ve noticed an increase in the usage of hidden AJAX requests designed to make a user’s action appear to happen immediately. I’ll refer to this type of AJAX request as non-blocking. It’s an AJAX request made without the user being aware it’s happening, it’s performed in the background and it’s operation is silent (there is no verbose to indicate a successful completion of the AJAX call). The goal is to make the operation appear that it has happen immediately when it really has not finished.

Here are examples of non-blocking AJAX request;

User clicks delete on a collection of emails. The items disappear immediately from their inbox, and they can continue with other operations. Meanwhile, an AJAX request is processing the deletion of the items in the background.
User fills out a form for new records. Clicks save. The new item appears in the list immediately. The user can continue to add new records.

To clarify, here are examples of blocking AJAX request;

User clicks delete on a collection of emails. An hourglass cursor appears. The AJAX request is made, and when it responds the hourglass cursor is turned off. The user has to wait a second for the operation to complete.
User fills out a form for new records. Clicks save. The form turns grey with an AJAX loader animating. A message is shown “Your data was saved”, and the new record appears in the list.

The difference between the two above scenarios is that a non-blocking AJAX setup does not provide feedback of an operating performing, and a blocking AJAX setup does.

The Risk Of Hidden AJAX Requests

The biggest risk of this style of AJAX request is that the web application could be in a completely different state when the AJAX request fails.

For example, a non-blocking example;

User selects a bunch of emails. Clicks the delete button. The operation appears to happen immediately (the items just disappear from the list). The user then clicks the compose button and starts typing a new email. It’s at this time that the JavaScript code discovers the AJAX request failed. The script could show an error message, but it really is pointless at this time.

Alternately, a blocking example;

User selects a bunch of emails. Clicks the delete button. Sees an hour glass, but the operation fails. They get an error message saying “error. blah blah blah”. They are returned back to the list of emails, and they still have the emails they wanted to delete selected. They could attempt to delete them again.

There are also other technical risks for performing non-blocking AJAX requests. The user could close the browser, could navigate to another website and they could navigate to another location in the current web that makes the context of any error response meaningless.

So Why Is It Becoming So Popular?

Facebook, Google, Microsoft, etc.. etc.. all these large domains are increasingly using non-blocking AJAX requests to make operations appear that they are performed instantly. I’ve also seen an increase in form editors that have no save or submit button. As soon as you leave a field or press enter. The value is saved. There is no your profile has been updated message or saving step.

AJAX requests are not a certainty, and shouldn’t be treated as successful until they have completed, but so many major web applications are operating just like that.

Are these websites that use non-blocking AJAX calls to simulate responsive applications taking an unnecessary risk at the cost of appearing fast?

Is this a design pattern that we should all be following in order to remain competitive?

It’s not so much “fake” performance as real responsiveness. There are a number of reasons why it’s popular:

Internet connections are fairly reliable nowadays. The risk of an AJAX request failing is very low.
The operations being performed are not really safety critical. If your emails don’t get deleted on the server, the worst that happens is you have to delete them again the next time you come to the page.
You can design your page to undo the action if the request fails, but you don’t really have to be that subtle because it means your connection to the server is broken. It’s easier to say “Connection lost. Unable to save recent changes. Try again later.”
You can design your page to only allow one pending AJAX request, so your state won’t get too out of sync from the server.
The browser warns you if you try to close or navigate away from a page while an AJAX request is pending.

Assuming something will work and displaying an error in case it fails on the remote side is much more user-friendly than blocking the user from doing anything else until there’s a response from the server.

An email client is actually a great example for this: When I have a list with 5 emails and the top one is selected I expect that when hitting DEL three times the first three emails are deleted. With “nonblocking AJAX” this works fine – everytime I hit the key the selected email is removed immediately. If something goes wrong an error is shown and either the not-properly-deleted emails are shown again OR the page is reloaded to get rid of the inconsistent local state.

So in the most common case – that is success – it improves the usability. In the rare case – failure – the usability is degraded (deleted element shows up again or the application is “restarted”) but when creating an application you usually want to have the best usability for common cases, not in case of errors.

The users don’t care about what your software is doing behind the scenes: they want their actions to have visible impact, and to be able to work at their pace.

If an action was successful on client side – like deleting emails – it’s your job to make it successful on server side as well. Why did the deletion fail? If it’s due to some kind of limitation (for exemple, you can’t remove an email that has been archived), the user should be made aware of that before his action failed.

If the error is caused by something more severe (let’s say a database crash), you should have a way to save the operation and re-try it when the system is up again.

A good exemple of managing this is the way Facebook handles the chat. There is no way to stop a user from disconnecting suddenly, which means they won’t be able to read the messages you sent before they left. Instead of displaying an error, the system saves all those messages and makes them available to the user when he comes back. No data is lost.

You can compromise between the two options. For example, if the user deletes an email, you could mark it red or grey it out until you get a confirmation back from the server, and only then remove it from the list. The user can still do other things while one action is pending, so it’s not blocking, but it still leaves a little reminder for the user that their actions haven’t been committed yet.

Amazon AWS takes this approach: when you stop/start an instance, the checkbox that allows you to select it turns into a spinner (so you can’t do anything to it for a few seconds), but this doesn’t block you from interacting with other instances.

I think, this comes together with more and more websites that try to behave like Applications and do more processing in the browser (like validating form data) than the more traditional sites. I don’t see too much of a problem in that as long as your code is reliable and you can expect it to succeed under normal conditions.

You say “It’s at this time that the JavaScript code discovers the AJAX request failed. The script could show an error message, but it really is pointless at this time.”

Why should it be pointless? You can go back in the list of EMails and do the delete again. Why wait instead? There is actually not much of a “risk” and they do not “appear” to be fast, they actually work faster. So if the activity is not “critical” why be slow?

My 2c is: there’s situations when it’s better to have, as you put it, “non-blocking” Ajax operations and others where it’s a bad design choice. Example: voting a YouTube video. You don’t really want any part of the page to be blocked while you click on the little starts there. It’s better to silently fail. Even a confirmation message would be over-kill. However your example with email deletion I’d qualify as mandatory for blocking-type Ajax request.

Mongo DB does something like that (and this could be considered as a Desktop application example). They have various “Write Concerns” for their operations, and you can configure it to different values for each operation, ranging from “return right away and don’t wait for anything” to “block until you’ve confirmation of successful network transfer and then return” to “wait till the content is properly scheduled for disk write on the remote machine before your return”. Obviously, if you make Desktop thick client (in like C++) using the Mongo driver, you’d set the lightest write concern for db operations of minimal “criticalness” (such as checking for new email), and others on more strict write concerns.

While I see the usefulness of non-blocking Ajax, I do agree with you that it’s happening too much. At a point there was at least one famous “social networking” site which would do this for photo uploading. You’d chose your photo to upload and then bam, right away it would tell you that it’s done, and then sure enough the next day when you wanted to add some more photos (or use on that you thought you already added), it was never to be found. Later on they gave up on this, and actually took the time to wait for response (and you would indeed sometimes get messages like “failed to upload photo, try later”).

Filed under: softwareengineering - @ 21:57

Thẻ: ajax, design, error-handling, javascript, web-development

Thiết kế website giá rẻ

Danh mục

How safe are hidden AJAX requests that fake performance?

What is a hidden AJAX request?

The Risk Of Hidden AJAX Requests

So Why Is It Becoming So Popular?