|
Size: 2263
Comment:
|
Size: 3304
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 12: | Line 12: |
| '''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. | '''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. |
| Line 20: | Line 20: |
| Recovery - WHEN CLEARING FIELDS, PROVIDE A WAY TO GET THE DATA BACK... | When a method is provided to clear a field, 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. |
| Line 22: | Line 22: |
| Autocomplete - | 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. |
| Line 24: | Line 24: |
| History - INDICATE DATES, ETC. | History, such as that used by web browsers, can be used to let users revisit specific locations without TypING MORE, ETC>>>> |
| Line 31: | Line 31: |
History sorted by date, using THAT ONE PATTERN... show dates esp. |
Problem
User entered data or subsidiary processes would be time consuming, difficult or frustrating to reproduce if lost due to accidental user-selected destruction.
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
Implicit protection methods are too varied to detail, so all the following will be ... XXXXXX
When a method is provided to clear a field, 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 TypING MORE, ETC>>>>
Presentation Details
Implicit protection methods are invisible to the user.
Autocomplete would ideally differentiate user entered vs. community or spell-check results
History sorted by date, using THAT ONE PATTERN... show dates esp.
When an undo process is provided from a clear field, or a history link is provided, LABEL IT...
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.