Submission Throttling

• Submission throttling solves the issue of when to send user data to the server.
• In a traditional web site or web application, each click makes a request back to the server so that the server is always aware of what the client is doing.
• In the Ajax model, the user interacts with the site or application without additional requests being generated for each click.
• In a traditional web solution data send back to the server every time when user action occurs. Thus, when the user types a letter, that letter is sent to the server immediately. The process is then repeated for each letter typed.
• The problem with this approach is that it has the possibility to create a large number of requests in a short amount of time, which may not only cause problems for the server but may cause the user interface to slow down as each request is being made and processed.
• The Submission Throttling design pattern is an alternative approach to solve this problematic issue.
• Using Submission Throttling, you buffer the data to be sent to the server on the client and then send the data at predetermined times.
  • Submission Throttling typically begins either when the web site or application first loads or because of a specific user action.
  • Then, a client-side function is called to begin the buffering of data.
  • Every so often, the user's status is checked to see if user is idle or not. If the user is still active, data continues to be collected.
  • When the user is idle, means not performing any action, it's time to decide whether to send the data. This determination varies such as, data is send only when it reaches a certain size, or data is sending every time when the user is idle.
  • After the data is sent, the application typically continues to gather data until either a server response or some user action signals to stop the data collection.
• Example: Google Suggest feature does this brilliantly. It doesn't send a request after each character is typed. Instead, it waits for a certain amount of time and sends all the text currently in the text box. The delay from typing to sending has been fine-tuned to the point that it doesn't seem like much of a delay at all. Submission Throttling, in part, gives Google Suggest its speed.

Predictive Fetch

• The Predictive Fetch pattern is a relatively simple idea that can be somewhat difficult to implement: the Ajax application guesses what the user is going to do next and retrieves the appropriate data.
• In a perfect world, it would be wonderful to always know what the user is going to do and make sure that the next data is readily available when needed. In reality, however, determining future user action is just a guessing game depending on user’s intentions.
• Suppose user is reading an online article that is separated into three pages. It is logical to assume that if user is interested in reading the first page, then user also interested in reading the second and third page.
• So if the first page has been loaded for a few seconds (which can easily be determined by using a timeout), it is probably safe to download the second page in the background. Likewise, if the second page has been loaded for a few seconds, it is logical to assume that the reader will continue on to the third page.
• As this extra data is being loaded and cached on the client, the reader continues to read and barely even notices that the next page comes up almost instantaneously after clicking the Next Page link.
• Example: This approach is taken by many web-based e-mail systems, including Gmail and AOL Webmail; During the writing of an e-mail, its general e-mail is for someone whom user knows, so it's logical to assume that the person is already in user's address book. To help out user, it may be wise to pre-load user's address book in the background and offer suggestions.

Fallback Patterns

• We pre-suppose that everything goes according to plan on the server-side: the request is received, the necessary changes are made, and the appropriate response is sent to the client. But what happens if there's an error on the server? Or worse yet, what if the request never makes it to the server?
• When developing Ajax applications, it is imperative that you plan ahead for these problems and describe how your application should work if one of these should occur.

Cancel Pending Requests

• If an error occurs on the server, meaning a status of something other than 200 is returned, you need to decide what to do. Chances are that if a file is not found (404) or an internal server error occurred (302), trying again in a few minutes isn't going to help since both of these require an administrator to fix the problem.
• The simplest way to deal with this situation is to simply cancel all pending requests. You can set a flag somewhere in your code that says, "don't send any more requests."
• This solution has maximum impact on the Periodic Refresh Pattern.

Try Again

• Another option when dealing with errors is to silently keep trying for either a specified amount of time or a particular number of tries.
• Once again, unless the Ajax functionality is key to the user's experience, there is no need to notify user about the failure. It is best to handle the problems behind the scenes until it can be resolved.
• In general, the Try Again pattern should be used only when the request is intended to occur only once, as in a Multi-Stage Download.