Increase Conversions in Long Web Forms by Resolving the Accidental Back Button Activation Issue

This article was originally published at Evolt and then Cone Trees in October, 2009.

Summary
The issue of accidentally activating the browser back button through the keyboard while interacting with a long web form is applicable to users across expertise levels. The time and effort wasted by the user can be said as proportional to the number of input fields filled by the user before accidentally exiting the page. Since no application feedback indicating cause of the error to the user is provided, depending upon user expertise, the user may or may not realize the cause of the error. Realizing what went wrong does not guarantee the possibility of reverting the error either.

This leads to unnecessary loss in form conversions despite favorable user intent. A solution to resolve this issue (that I hope becomes standard practice) to plug the hole for lost conversion that translates to big numbers in absolute terms for high traffic websites is also provided.

---

Note
In this article, a long web form refers to a form on a website or a web application that requires the user to complete constitutes of more than five input fields (this includes text input fields- text boxes and/ or text areas) on a page.

What is the issue?

In the case of a long web form that a user attempts to complete, if the user wants to delete text from a text input field but fails to focus on it and then hits the backspace key (which is the shortcut key for the browser back button), the back button is activated and the form page is exited and returns to the previous page, much to the surprise of the user who has no idea what just happened.

The issue is that the web form does not provide any form of feedback to the user about what happened assuming that this was a conscious decision by the user.
This is a shortcoming because in this particular case where the user has already filled a number of input fields, and the browser back button is activated through the backspace keyboard shortcut and not the mouse, there is a higher probability of the user exiting the form by accident rather than with intent.

The scenario below should help you understand it better.

Scenario

1. User arrives at the long web form through a link that opens the same window (thus enabling the back button)
2. User begins filling the form and completes inputting data in a minimum of 4-5 input fields.
3. User wants to delete text present in a text input field(either pre-populated or typed in by user).
4. Case A
   1. User attempts to bring the text input field to focus using the mouse (not the keyboard). After this the user plans to use the keyboard backspace key to delete the text contained within.
   2. User accidentally fails to use the mouse to target the text input field and the focus is on page instead of any input element.
   3. Assuming the text input field is in focus, the user then hits the backspace key (which is the shortcut key for the browser back button). Since the focus is upon no input field, the browser back button activates and the user returns to the previous page.
   4. End
5. Case B
   1. User attempts to bring the text input field to focus using either mouse or the keyboard ‘tab’ button to switch between input fields and then use the backspace key to delete the text contained within.
   2. User accidentally fails to bring focus upon the text input field and the focus is on a non-freeform input field. on any input field that does not allow freeform input (e.g.- not a text input field or an input area, but a combo box or a radio button).
   3. Assuming the text input field is in focus, the user then hits the backspace key (which is the shortcut key for the browser back button). Since the focus is upon no input field, the browser back button activates and the user returns to the previous page.
   4. End

Understandably, more the number of fields filled, more the frustration of the user upon accidentally going back from the form page. It’s easy to understand that this won’t happen by the user first locating the browser back button, then reaching there with the mouse and then clicking it. But its easy to understand that it can happen that the user fails to focus upon an input field and hits the back button (which is equivalent to clicking the back button in every popular browser), thereby taking the user back to the previous page he came from.

Frequency and criticality

The occurrence of issue may be low in frequency, but at the same time it is high in criticality because the end result may be a failed conversion if the user abandons the idea of completing the form due to lack of time available, alternate choices available or wasted time and effort acting as factors for discouragement.

Novice and expert users- disorientation, frustration, possible realisation and recovery

Based upon my observation as facilitator over a large number of usability tests on different websites involving long forms, I can safely say that in such a case, the user is frustrated when this happens. This frustration is more or less directly proportional to the number of input fields filled in the form. More the number of form fields filled by the user before accidentally exiting it and returning to the previous page, more is the time and effort wasted by the user.

Users of varying expertise experience the issue differently. If the user is a novice internet user, the user will fail to understand what happened and probably think the application or self is at fault. Either way, the user will be discouraged from using the form, or worse so, if an alternate is available, the application itself. This bad user experience is bound to hurt brand value of the product.

On the other hand, an intermediate or expert user may understand what happened but might still not be able to recover by clicking the forward button yet depending upon the technical implementation of the form.

Upon accidental exit from the form, this is the pattern I have noticed in novice and expert users upon accidentally exiting the form they were in process of completing:

Novice User

1. Disorientation due to unexpected application behavior (user thinks that the backspace key will delete text in text input field but failure to focus on text input field causes exit from the form page and the users return to the previous page).
2. Inability to understand what happened.
3. Frustration due to unexpected application behavior and inability to complete task as planned.
4. User blames either self or application for unexpected error.
5. User may abandon attempting form again due to lack of time or other online and offline choices available to complete task.
6. Poor online experience due to failure of application to help user complete task as expected leads to damaged brand image.
7. User may choose to abandon using website based upon poor online experience.

Expert User

1. Disorientation due to unexpected application behavior (user thinks that the backspace key will delete text in text input field but failure to focus on text input field causes exit from the form page and the users return to the previous page).
2. Subsequent realization as to what went wrong knowing the backspace key caused the exit from the form page.
3. Frustration due to error made by self (or keyboard design in general).
4. User may abandon attempting form again due to lack of time or other online and offline choices available to complete task or;
5. Attempt to recover from error in hope to continue from the last field filled; the user may or may not be successful depending upon technical implementation of form.
6. Failure to recover from error may cause user to abandon attempting form again due to lack of time or other easier online (shorter forms) and offline choices available to complete task

A proposed design solution to the issue of accidental back button activation in long web forms

Need for adoption

Hoping this solution becomes standard practice- a pattern, the proposed solution is proposed for the very fact that it is not seen anywhere. I had a look at some long web forms on websites in the Alexa Top 60 and none of them had taken care of this loophole. These websites included Hotmail, Yahoo! Mail, Gmail, Hotmail, WordPress, Blogger, IMDB, AOL, Craigslist, Orkut, Apple, Adobe and ESPN to name a few.

Easy to implement and justify- low level of effort (LOE) and code weight

Considering the huge amount of traffic these websites receive everyday, this solution will help save a huge amount in terms of absolute numbers (relatively how ever small it may be). The proposed solution requires little programming effort as corrective action to help resolve the issue and thereby help increase form conversions. While the occurrence of the issue, justification for implementation of the solution is apt since any amount of conversion increased is good, considering the low level of effort (LOE) required to implement this solution and minimal addition of code.

Solution to the issue of accidental back button activation in long web forms

The solution is to detect activation of the back button when there is higher probability that the action of activating the back button through the ‘backspace’ keyboard shortcut was an accident rather than done intentional.

1. Detect activation of back button done through the ‘backspace’ keyboard shortcut.
   Activate the detection after a minimum number of fields have been filled in where you thing the user has utilized considerable mental and physical effort. Set this number based upon the effort required by the user to complete these fields. For example, you may set this after 5 input fields that require close-ended answers from the user. On the other hand you may set this after the first input field in a form where you require the user to enter an open-ended answer in a text area since the user has to utilize more mental effort and physical effort to fill it in comparison to the former.
2. Provide feedback of the event to the user explaining that the back button was activated and request confirmation whether it was intentional or accidental.
3. The user can now decide whether to return to the previous page or continue completing the form, thereby averting the accident.

Confirmation can be requested using a confirmation dialog box, either using standard UI or emulated using layers. The advantage of the former is that it loads instantly uses ‘OK’ and ‘Cancel’ labels for buttons. The advantage of the later is the freedom to assign descriptive labels to the buttons. Choosing between the two will be determined by your style guide.

(Standard UI Confirmation dialog box in Firefox on Windows)

(Mockup of UI that emulates a Confirmation dialog box, often accomplished through DHTML)

I advise the following guidelines for using the confirmation dialog box effectively:

1. As the focus by default is on OK, craft your description in relation to your action buttons in such a way that OK is the value that keeps the user on the form page since this solution is based upon higher probability of the user wanting to stay on the form page.
2. You can always change the description to make it shorter (as long as it does not compromise with the effectiveness of the description) but use double line spacing to increase readability. At a time when the confirmation box acts to reorient the user, the dialog box must be as simple to read as possible, lest it be neglected by the user who may select a button without reading the description in it.