Problem

Users must be able to remove contents from fields, or sometimes whole forms, without undue effort and with a low risk of accidental activation.

Option menus, such as this contextual menu on a touch device, offer options for dealing with text already. Adding a clear function may not be natural but a dual-purpose function with automatic recovery like this “Cut all” function can be a very convenient way to include it. The users is additionally lead to develop a mental model that includes this, from their more frequent use of typical editing functions.

Solution

Just as text entry on mobiles is difficult, removing already filled-in values can be exactly as difficult and even more tedious without assistance. Long URLs, or other old, pre-populated or pre-filled data may be inaccurate, and can be slow to clear.

Clear functions should only rarely be used, and can be dangerous as they may accidentally encourage deletion. But they should be considered for some types of forms.

Additionally, the Clear button does not allow selection of individual fields. Even on touch devices, it can be difficult to use conventional desktop paradigms of selection and deletion, so without additional assistance users have to resort to repeated keystrokes and other time-consuming actions. To make matters worse, certain actions we take as designers to prevent loss of data can make it hard to get around; discarding a text message, for example, often saves it as a draft and there is sometimes no way to get around this.

A series of functions and tactics should be considered to assist the user with this task, without conflicting with primary tasks, and principles of preservation of data.

Variations

Most Clear Entry functions for mobiles are at the field level, and these almost always empty text Input Areas:

Form level clear and rest buttons are discouraged, but can be useful in some processes. Additionally, do not overlook the possibility that your form may have essentially one field in it. An SMS application can use a clear button

Interaction Details

Clear Entry functions should not be automatically included, but should always be considered. Think of all form design -- as you think of all interactive design -- in the context of the user. If repeated use of a field is likely, or there is no other way to abandon the information, then a method may be needed to clear the input.

Explicit functions may be buttons adjacent to the field, or options available in a menu. These may overlap with the intent of the implicit function by simply offering a "Cut All" function; this has other purposes and in fact loads the clipboard with the data, but also serves to clear the field.

Classic implicit functions over-drive the key repeat. The typical user will, when faced with a large delete task, simply enter the field and begin pressing the delete key. Many will be aware of key repeat, so will keep the key pressed down if the whole field must be cleared. Key repeat usually has a relatively low maximum speed, to allow for stopping at a specific point. If this is unlikely, such as in the URL field example, or after a longer than usual time, the repeat may accelerate.

This may be a very marked acceleration, even to the point where the entire field is suddenly deleted within a fraction of a second. This must always be coupled with behavior that stops keypresses at the end of the field, and does not move to the next field in line without the user stopping the action, even if the Back key is used to cycle to the previous in focus area otherwise. This behavior can be applied to arrow keys when used for selection as well, but is not applied to other keys.

These variants and examples should not rule out other methods being developed or used, such as gestural clear functions. However, these have not yet developed into a regularized enough set to be considered a pattern or variant, so cannot be discussed further at this time.

For all of these actions, use the principles of Cancel Protection. Explicit cancel guards are not usually needed if the control is well designed, but saved states, or other paths to retrieve the information should often be developed. URLs can usually be revisited with the existing history functions, and the "Cut All" menu option described above does save the cut data to the clipboard; pasting will recover it.

Presentation Details

Label all buttons, menus and other functions clearly. Rarely can a reset function be a compact button, labeled only with a graphic, due to the potentially catastrophic loss of information. Use text labels when possible.

Be sure to label clearly. Clear, reset and cut are very different actions with different implications. Do not confuse terms or assume the user base is not savvy enough to understand.

Even on the desktop web, the Clear button is massively over-used, and causes errors more than it fulfills real use cases. This very small form has no need for such a button, and it is also undifferentiated from the other two, and far too close. Even if identified, it can easily be accidentally activated. Live functions such as high speed key repeat, or gestures to select or delete functions, must show the action happening in real time. If the screen cannot update at the speed of the actual behavior, do not use the function. Even at maximum speed, the user must be able to release the key and expect to have the cursor stop where they see it at that moment.

Always use conventional display methods for exaggerated behaviors. Selection at high speeds should use the same highlighting as normal selection, for example.

Antipatterns

Form level Clear buttons, if used, must be very carefully placed to avoid accidental activation and should still often use explicit Cancel Protection methods.

Examples