|
Size: 629
Comment:
|
Size: 2264
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ...they are very similar in interaction, BUT are very different cases.Exit an app or process, vs. cancel an action (e.g. abandon a text field that might have taken a long time to enter stuff on). Exit can usually live with interstitials, but cancel often must be more inline. Or maybe even other methods of protection such as saving data, allowing exit, but then telling user they can go back to enter it again... Refer to clear fields in text entry as well... |
|
| Line 4: | Line 2: |
| User entered data or subsidiary processes would be time consuming, difficult or frustrating to reproduce if lost due to accidental user-selected destruction. | |
| Line 7: | Line 6: |
| Processes must be designed to protect user input. Methods must be provided to recover previous and historical entry. | |
| Line 10: | Line 10: |
| 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. |
|
| Line 13: | Line 18: |
| Implicit protection methods are too varied to detail, so all the following will be ... XXXXXX Recovery - WHEN CLEARING FIELDS, PROVIDE A WAY TO GET THE DATA BACK... Autocomplete - History - INDICATE DATES, ETC. |
|
| Line 16: | Line 28: |
| Implicit protection methods are invisible to the user. Autocomplete would ideally differentiate user entered vs. community or spell-check results When an undo process is provided from a clear field, or a history link is provided, LABEL IT... |
|
| Line 19: | Line 36: |
| 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. |
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
Recovery - WHEN CLEARING FIELDS, PROVIDE A WAY TO GET THE DATA BACK...
Autocomplete -
History - INDICATE DATES, ETC.
Presentation Details
Implicit protection methods are invisible to the user.
Autocomplete would ideally differentiate user entered vs. community or spell-check results
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.