Differences between revisions 17 and 18
Revision 17 as of 2010-11-09 04:51:30
Size: 4841
Editor: shoobe01
Comment:
Revision 18 as of 2010-11-09 04:53:37
Size: 5008
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
{{attachment:CancelProtection-History.png||align="right"}} {{attachment:CancelProtection-History.png|History works best when built as a Hierarchical List. For recovery of accidentally deleted user input, consider contextual use, such as loading the list into a Pop-Up.|align="right"}}

Problem

User entered data or subsidiary processes would be time consuming, difficult or frustrating to reproduce if lost due to accidental user-selected destruction.

When a Clear Field widget is provided, an "Undo" button can be used to undo accidentally erased information.

Solution

Processes must be designed to protect user input. Methods must be provided to recover previous and historical entry.

Variations

One of the key Principles of Mobile Design is to respect user-entered data. Design processes and interactions to avoid loss of data. Design technical systems such as storage methods to automatically save entries and present them for retrieval. Two specific types of interactive design cases must be considered:

Implicit protection: Design interactive methods to avoid exit or deletion. Take the example of deleting characters in a form field. If the convention in the OS would make an additional delete keypress exit the field, and grant focus to the previous field, do not do this on automatic key repeat. This will avoid accidentally deleting the entry in multiple fields. Add a pause, or a hard stop, so the user must release and re-press the delete key.

Explicit protection: When a single function is provided to clear user entry, provide a method within the screen to allow recovery of the user-entered data.

Interaction Details

Be sure to differentiate historical, user-entered Autocomplete entries from other sorts of result, separating and labeling. Implicit protection methods may use any interactive or systematic methods, or any patterns outlined in this book. To find them, consider how any interactive system can be mis-used. Often very small changes, such as the buffer clearing described above, can alleviate them. Larger changes must be considered carefully, so that primary use cases guide the design, not rare or edge cases.

When the Clear Field widget is provided, and that method has been used, then as long as the session is active another function will be present that will recover the cleared information and display it in the field. If this is used when there is new content in the field, the user should be asked if they want to add it to the newly-entered information, or replace with the recovered entry.

Autocomplete processes should save user entries a they are being typed, so they are available for autocomplete even when accidentally deleted or an accidental loss-of-session (such as loss of signal) occurs. When entry into fields may be tedious, repetitive or recovered user entry is available, display the autocomplete list of options as soon as a match is found with the current entry. To avoid over-using autocomplete, do not attempt to match until a few characters have been typed. The exact number will vary by type of entry, and processing capacity of the device.

History, such as that used by web browsers, can be used to let users revisit specific locations without recalling and re-entering the same address, search or other information. This should be displayed as a Hierarchical List grouped by session.

Presentation Details

History works best when built as a Hierarchical List. For recovery of accidentally deleted user input, consider contextual use, such as loading the list into a Pop-Up. Implicit protection methods are invisible to the user.

For details on general Autocomplete presentation, see that pattern. For the purposes of recovering user information, an indicator should also differentiate user-entered information vs. community or spell-check results, if several types are offered.

Displaying history with a Hierarchical List is essentially as described in that pattern. Parents should be labeled by the date and time the session occurred, using natural language to account for ranges; "Yesterday afternoon" is more clear than "1:20-3:45 pm, 7 November."

When an undo process is provided from a clear field, or a history link is provided, make sure it is clearly labeled or uses a well-understood iconic representation. If the OS uses a standard "back" or "cancel" icon then that is often a good choice and will fit the existing interactive language. Text labels should either label the direct activity such as "History" or the recovery task, such as "Recent entry."

Antipatterns

Do not preserve secure information such as passwords and financial transaction information without informing the user.

Do not store any information as plain text that can be searched remotely or when stored as backup files. It is difficult to tell what information is secure to the user, and one person's public knowledge may be another's secrets. Assume everything is worth at least minimal protection.

Examples

Cancel Protection (last edited 2013-04-11 00:01:37 by shoobe01)