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 - Explicit Submission (Page 4 of 7 )
Submit, Packet, Performance
Figure 1-6. Explicit Submission
Developer Story
Devi's producing an Ajax chat web site. She decides text will only be transmitted after the user explicitly clicks a "Done" button.
Problem
How can information be submitted to the server?
Forces
It's difficult for the server to cope with lots of messages at once.
Each message has overheads, such as packet headers, and requires some processing at each stage of the browser-server round-trip.
Users often need to manipulate a small work unit privately, and then upload it as a whole atomic unit to the server.
Solution
Instead of automatically submitting upon each browser event, require the user to explicitly request it; e.g., submit upon a button click. Typically, the user performs some work for a few seconds or minutes, and then clicks a button to tell the server. It's a familiar pattern on the Web as it feels similar to standard form submission.
The most common example is a text field, which may be an input or textarea control. While it would be possible to transmit keystrokes as they happen, that's often not desir able. In a wiki, for instance, imagine what would happen if a user deleted a paragraph in order to replace it. Any other user viewing the wiki would see the paragraph disappear! Furthermore, the history would reflect that transition state.
Where there's only one input field, it sometimes makes sense to rely on onchange or onblur events to detect that the change has been made. But how about when there are several closely related fields? Even then, some automatic submission is okay, to provide some validation information, for instance. However, if the information is important enough to cause a change to the server, Explicit Submission is a good way to ensure the user intended what's been uploaded.
As well as some inconvenience, the downside of relying on the user to explicitly submit data is...what if the user doesn't? Have you ever quit the browser and forgot to submit a form you were working on? The consequences may be minor for a query-and-report application, but for data entry applications, large amounts of work can be lost when the user forgets to submit it or doesn't realize its necessary to do so. For that reason, Explicit Submission can sometimes be complemented by automated Submission Throttling. For instance, Gmail (http://gmail.com) will only send mail upon an Explicit Send command, but nonetheless has an Autosave feature that will periodically upload an in-progress message as a draft.