AjaxPatterns
Submit, Packet, Performance
Devi's producing an Ajax chat website. She decides text will only be transmitted after the user explicitly clicks a "Done" button.
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, then upload it as a whole, atomic unit, to the server.
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 desirable. 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 realise it's necessary to do so. For that reason, Explicit Submission can sometimes be complemented by automated “Submission Throttling”. For instance, GMail 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.
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", "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 utilising the keyboard, 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. And 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.
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 they've grown impatient and begun banging on the mouse button or the Enter key. A few coping strategies:
Limit frequency of submissions with “Submission Throttling”. While that pattern emphasises automated submissions, it's still possible to throttle Explicit Submissions.
After a user has made a submission, use “Page Rearrangement” to remove the submission button.
Soothe impatient users with “Progress Indicator”s and “Guesstimate”s.
Prevent excessive delays with ???s like “Predictive Fetch”.
Show the initial Submission control in a “Popup”, 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” helps here because RESTful Services can handle such situations gracefully, e.g. rejecting any invalid queries.
Brett Stimmerman's Lace Chat is an Ajax chat application. Lace users type the entire message and then explicitly submit with a "Say" button. You can also hit Enter after typing the message. Most chat applications work this way. It's a little more efficient, but the main benefit is actually for the user. It would potentially be confusing to other users to see a partially-constructed message, and the composer of that message would often like to rectify any errors before posting the message.
"The Fonz" text adventure is a command-line game (Figure 1.28, “The Fonz”). In typical command-line fashion, you type something and submit the whole command at once. Interestingly, command-lines don't have to work that way - it's feasible to provide hints as the user types, or some validation support. The Assistive Search Demo illustrates this point.
A9, as with many search engines, requires Explicit Submission before it searches for the user's query (Figure 1.29, “a9search”).
The Basic Sum Demo illustrates Explicit Submission. In the basic case, there are some input fields and a button, just sitting in a div:
<div>
<div id="figure">
<input type="text" class="figure" id="figure1"
name="figure1" size="3" value="4"/><br/>
<input type="text" class="figure" id="figure2"
name="figure2" size="3" value="6"/><br/>
<input type="text" class="figure" id="figure3"
name="figure3" size="3" value="" /><br/>
</div>
<input type="button" id="addButton" value="Add" />
</div>
The button is configured to submit the form when it is clicked, an example of Explicit Submission:
$("addButton").onclick = function() {
submitSum();
}
We now refactor to an alternative form of Explicit Submission, in which a standard form makes the submission. It's still an "Ajax submission" involving no page refresh, but leverages the standard form mechanism. There are two reasons you might do this in real life: (a) it's a step towards graceful degradation, since non-Javascript browsers will require the data to be held in a standard form; (b) it will "feel" more like a form to the user, e.g. the Enter key will automatically submit, and any CSS styling for forms will apply to it.
The initial HTML has been wrapped by a form tag. With standard Javascript enabled, the action URL makes no difference because it will never be accessed, but if we wanted, we could point it to a conventional server-side script which would process the form in the event Javascript is turned off. The regular button control has been replaced by a submit button:
<form action="http://ajaxify.com/run/sum/form/">
<div id="figure">
<input type="text" class="figure" id="figure1"
name="figure1" size="3" value="4"/><br/>
<input type="text" class="figure" id="figure2"
name="figure2" size="3" value="6"/><br/>
<input type="text" class="figure" id="figure3"
name="figure3" size="3" value="" /><br/>
</div>
<input type="submit" id="addButton" value="Add" />
</form>
The script hooks into onsubmit, which will be called when the new submit button is clicked. It arranges for an XMLHttpRequest submission via submitSum(), then returns false to prevent a conventional form submission and page refresh:
$("sumForm").onsubmit = function() {
submitSum();
return false;
}
“Submission Throttling” talks about automated, periodic, submissions, where the present pattern is about the user forcing submissions to take place. The patterns can certainly be combined. Consider text editors which often harden their explicit "Save" mechanisms with automated backup. An Ajax app can use automated submissions, but allow for manual intervention when the submission must take place "NOW".
“Live Form”s often use onblur and onfocus events, a subtle type of Explicit Submission.
Follow up submissions with a “Progress Indicator” to give some feedback.