Explicit Submission

Time your website with WebWait - from the creator of AjaxPatterns.org

From Ajax Patterns

Archived Version
There's an archived version of this pattern available, taken from the Ajax Pattern book draft, showing roughly how it appeared before the page became publicly editable.

Evidence: 3/3

Tags: Submit Packet Performance

[edit]

In A Blink

Chat application with pointer over "Send!" button.

dsdsassdads

[edit]

Goal Story

Tracy is holding an online meeting on an Ajaxian chat program. When she is done typing her entire message, she clicks the "Done" button. Only then is the message sent to the server.

[edit]

Problem

How can information be submitted to the server?

[edit]

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, then upload it as

a whole, atomic unit, to the server.

[edit]

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 is 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 infromation 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 improving reliability of call data, explicit submission can be used as an optimisation strategy. The user knows when a unit of work is complete, so a remote call occurs only when the user tells the system.

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? Personal experience working with support staff tells me I'm not the only one here. The consequences may be minor for a query-and-report application, but for data entry applications, it's possible large amounts of work can be lost when the user forgets to submit it, or doesn't realise it's necessary to do so.

A good trick is to use a form. In an Ajaxian application, the form need not actually be submitted, but it will leverage the browser's support for keyboard handling. When the user hits Enter anywhere on a form, most browsers will attempt to submit the form. You can exploit this behaviour for any group of related fields where hitting Enter should perform some activity. Just include a regular submit button and register an onsubmit handler to handle the event, making sure it always returns false. In doing so, you avoid directly setting an onkeypress listener on each field.

[edit]

Decisions

[edit]

How will the user request the submission?

The submission mechanism should ideally be similar to those in similar non-Ajaxian 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 siginificant keystroke, usually Enter, can also work in the right context, and, by utilising the keyboard, supports power users.

Relying on onblur might be referred to as an 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, they 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.

[edit]

Will multiple submissions be allowed in succession?

Have you ever made a credit card purchase where a fear-inducing warning appears: "Do not submit this form twice. If you do, really bad things will happen to you like losing twice as much money as you expected. YOU HAVE BEEN WARNED!". What they're trying to prevent is two separate form submissions occurring, leading to double processing and twice the cost to you.

There's a very human reason why message like this exist: users naturally get impatient when they're waiting for something. Especially in the absence of a Progress Indicator, how can the user know the system's still working on their problem? Furthermore, concepts about event queues and buffering are not part of users' mental model. From most user's perspective, if the page isn't doing anything, they may as well keep clicking.

In the credit card case, there are various solutions to the problem - a unique form ID (token) for starters. And a Progress Indicator to let the user know what's going on. But even these measures still won't stop impatient users from clicking. In fact, what users often don't realize is that they are usually doing themselves a disservice by continuously clicking, because the original request takes longer to process once all the others have been spawned. That's especially true on intranet applications, where each individual user effectively controls a large proportion of processing activity, sometimes all of it.

One way to help users help themselves is to simply suppress the submission mechanism until either the server responds or a timeout occurs. This is a viable technique when there is a risk the same entity will be altered. Thus, a submission button for a wiki paragraph might realistically be disabled while the paragraph is submitted. But should the user be prevented from submitting neighbouring paragraphs? Probably not, but it's still possible if server resources are limited.

[edit]

Real-Life Examples

[edit]

Lace Chat

Brett Stimmerman's Lace Chat is an Ajaxian 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.

[edit]

The Fonz

"The Fonz" text adventure is a command-line game. 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 Live Search Demo illustrates this point.

[edit]

A9

A9, as with many search engines, requires explicit submission before it searches for the user's query.

[edit]

Refactoring Illustration

[edit]

Sum Demo: Introducing a Form

The basic Sum demo illustrates Explicit Submission. Let's first see how that's achieved, and then refactor to a different type of Explicit Submission, based on a form.

In the basic case, there are some input fields and a button, just sitting in a div.

     <input type="text" class="figure" id="figure1"
            name="figure1" size="3" value="4"/>

     <input type="text" class="figure" id="figure2"
            name="figure2" size="3" value="6"/>

     <input type="text" class="figure" id="figure3"
            name="figure3" size="3" value="" />

   <input type="button" id="addButton" value="Add" />

The button is configured to submit the form when it is clicked, an example of Explicit Submission:

 $("addButton").onclick = function() {
   submitSum();
 }

One problem here is that users might like to submit by typing Enter. That's a common expectation in conventional applications and it seems reasonable here too. At present, Enter has no effect, but we can easily change that by wrapping a form around the fields, and changing the button to become a submit control. Here's <a href="http://ajaxify.com/run/sum/form the refactored version]:

 <form action="http://example.com"">

     <input type="text" class="figure" id="figure1"
            name="figure1" size="3" value="4"/>

     <input type="text" class="figure" id="figure2"
            name="figure2" size="3" value="6"/>

     <input type="text" class="figure" id="figure3"
            name="figure3" size="3" value="" />

   <input type="submit" id="addButton" value="Add" />

 </form>

Okay, it looks the same as before, but now it's a form. The form action is "http://example.com", and it's included for XHTML compliance. You can change it to your own domain name, but it really doesn't matter because it will never get there. That's because onsubmit returns false after carrying out the user's intended action.

 $("sum").onsubmit = function() {
   submitSum();
   return false;
 }

Everything still looks the same as before. But, after this little refactoring, you can hit Enter anywhere in the form to submit the sum. You can also click the Add button, as before.

[edit]

Alternatives

[edit]

Submission Throttling

Submission Throttling is the counter-pattern to Explicit Submission. The emphasis there is on automated, periodic, submissions, where the present pattern is about the user forcing submissions to take place.

The patterns can certainly be combined. Consider editing applications like MS-Word or Vim. Typically, there is an explicit "Save" mechanism as well as an auto-backup feature. So an Ajaxian application can use automated submissions, but allow for manual intervention when the submission must take place "NOW".

[edit]