Section 10.4. Explicit Submission

10.4. Explicit Submission

Submit, Packet, Performance

Figure 10-6. Explicit Submission

10.4.1. 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.

10.4.2. Problem

How can information be submitted to the server?

10.4.3. 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.

10.4.4. 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 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 realize it's 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.

10.4.5. Decisions

10.4.5.1. 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 conductedfor 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.

10.4.5.2. 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.

10.4.6. Real-World Examples

10.4.6.1. Lace Chat

Brett Stimmerman's Lace Chat (http://www.socket7.net/lace/) 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 might be confusing to other users to see a partially constructed message, so the composer of that message should rectify any errors before posting the message.

10.4.6.2. The Fonz

"The Fonz" text adventure (http://www.mrspeaker.webeisteddfod.com/2005/04/17/the-fonz-and-ajax/) is a command-line game (Figure 10-7). In typical command-line fashion, you type something and submit the whole command at once. Interestingly, command lines don't have to work that wayit's feasible to provide hints or some validation support as the user types. The Assistive Search Demo (http://ajaxify.com/run/assistiveSearch/) illustrates this point.

Figure 10-7. The Fonz

10.4.6.3. A9

A9 (http://a9.com), as with many search engines, requires Explicit Submission before it searches for the user's query (Figure 10-8).

Figure 10-8. A9 search

10.4.7. Code Refactoring: AjaxPatterns Form-Based Sum

The Basic Sum Demo (http://ajaxify.com/run/sum) illustrates Explicit Submission. In the basic case, there are some input fields and a button, just sitting in a div:

   <div>     <div >       <input type="text"                 name="figure1" size="3" value="4"/><br/>       <input type="text"                 name="figure2" size="3" value="6"/><br/>       <input type="text"                 name="figure3" size="3" value="" /><br/>     </div>     <input type="button"  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 (http://ajaxify.com/run/sum/form) makes the submission. It's still an "Ajax submission" involving no page refresh, but it leverages the standard form mechanism. There are two reasons you might do this in real life: it's a step towards graceful degradation, since non-JavaScript browsers will require the data to be held in a standard form; it will "feel" more like a form to the usere.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 want, we could point it to a conventional server-side script that would process the form in the event that JavaScript is turned off. The regular button control has been replaced by a submit button:

   <form action="http://ajaxify.com/run/sum/form/">     <div >       <input type="text"                 name="figure1" size="3" value="4"/><br/>       <input type="text"                 name="figure2" size="3" value="6"/><br/>       <input type="text"                 name="figure3" size="3" value="" /><br/>     </div>     <input type="submit"  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;   } 

10.4.8. Alternatives

10.4.8.1. Submission Throttling

Submission Throttling (see earlier) 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 that 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.

10.4.9. Related Patterns

10.4.9.1. Live Form

Live Forms (Chapter 14) often use onblur and onfocus events, a subtle type of Explicit Submission.

10.4.9.2. Progress Indicator

Follow up submissions with a Progress Indicator (Chapter 14) to give some feedback.

10.4.10. Metaphor

An author drafts each chapter of a book in entirety before submitting it for editorial review.