Submission Throttling and the Browser-Server Dialogue
The second part of this series of articles dealing with browser-server information flow discussed periodic refreshing. This one covers submission throttling and explicit submission. The third of a multi-part series, this article is excerpted from chapter 10 of the book Ajax Design Patterns, written by Michael Mahemoff (O'Reilly, 2006; ISBN: 0596101805).
Submission Throttling and the Browser-Server Dialogue - Decisions about Explicit Submission (Page 5 of 7 )
How will the user request the submission?
The submission mechanism should ideally be similar to those in similar non-Ajax systems.
Buttons are one common idiom, with a generic label like Submit, Done, or Go!. More meaningful names are usually clearer, being specific to the task being conducted--for instance, "Buy," "Search," or "Delete." Buttons have the benefit of making the Explicit Submission mechanism stupidly obvious: "I click the button, the info's submitted; I don't click it, it's not submitted."
Relying on a significant keystroke, usually Enter, can also work in the right context, and, by using the keyboard, it supports power users.
Listening for the onblur is another explicit technique, albeit with a submission mechanism that is not apparent from the UI. The nice thing about onblur is that the application can continue submitting without interrupting the usual flow of events. On a Live Form, for instance, users can force a submission with Tab or Shift-Tab, which they would have hit anyway to move out of the tab. It also means the user can click somewhere else on the mouse to force a submission. The downside is the risk of accidental submission. There's also the question of what the user can do to prevent a submission occurring, having already begun typing something? Perhaps they can blank the field, but clearly, communicating this to the user is not easy.
How will you deal with frequent submissions?
Explicit Submission leaves open the possibility of too many submissions at once. This might happen because the user is working too fast, or simply because he has grown impatient and begun banging on the mouse button or the Enter key. A few coping strategies are as follows:
Limit frequency of submissions with Submission Throttling (earlier in this chapter). While that pattern emphasizes automated submissions, it's still possible to throttle Explicit Submissions.
After a user has made a submission, use Page Rearrangement (Chapter 5) to remove the submission button.
Soothe impatient users with Progress Indicators (Chapter 14) and Guesstimates (Chapter 13).
Prevent excessive delays with Performance Optimizations like Predictive Fetch (Chapter 13).
Show the initial Submission control in a Popup (Chapter 15), and then close it upon submission. This is sometimes used for login forms.
No matter how you prevent multiple submissions, be sure to design the server so it can cope with them. RESTful Service (Chapter 9) helps here because it can handle such situations gracefully; e.g., by rejecting any invalid queries.