|
Size: 2403
Comment:
|
Size: 3503
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 6: | Line 6: |
| 1) Try to avoid it. Often, operators of systems default to timeout for security or to be cheap on scale. There may be other ways to solve this with clever context servers... LOOK UP SOLUTIONS... ALso: Mobiles are personal, so less worry for handset-like devices than desktop web, kiosks, etc. Do not default to old-school security practices... | Try to avoid the use of timeout as a solution to load and security. Affinity based load balancing is the default due to simplicity with sharing user data, but requires session-startup processes or leaving overhead for all predicted users for a particular server. There are other methods, so if system and data design is within scope of your project, consider these as part of the overall experience design. |
| Line 8: | Line 8: |
| 2) Try to work around it. Use sensors (even cameras) to detect if the user has left, or changed (or for mobiles, if the device has been set down and is not being used at all). Timeout dialogues are based on desktop paradigms, where the computers do not have sensors. | If sessions must expire due to the method by which they have been built already, consider making this transparent. Keep a log of the last-used location in the system, and when the user initiates new activity, resume at that state. |
| Line 10: | Line 10: |
| 3) If you have to have it: A modal dialog appears describing the impending loss of session (and why, e.g. security or availability). | Mobiles are personal, so there is generally less worry about security of individual applications than on the desktop web, or for kiosks. Do not use old-school security practices by default, and only use when needed. |
| Line 12: | Line 12: |
| If anything less intrusive than a modal dialogue, it often will not be seen. | If session expiry is required for security purposes, try to work around it using sensors to detect when a user leaves or puts the device down for some time. Timeout dialogues are based on desktop paradigms, where the computers do not have sensors. |
| Line 14: | Line 14: |
| Dialogue will be a sort of reverse Exit Guard, and allow cancelling, but the primary function is to resume work, which resets the timer. If you don't touch a button on the dialogue, it has an internal secondary timer, so after a brief time, the session is lost. At this time, a modal dialogue will appear briefly to tell the user the session has ended, then the system will return to it's idle state, or exit (to the idle screen) entirely, depending on the behavior of the system. |
When a strict timeout is needed, a modal dialog appears describing the impending loss of session and presenting methods to preserve the session. When expired, additional information will be presented, and the user will be required to sign on again. |
| Line 28: | Line 26: |
| SENSORS: Cameras can to detect if the user has left, or changed (or for mobiles, if the device has been set down and is not being used at all). Motion sensors, etc. can tell if the device was left alone; coupled with no input, this can cause a "session timeout" dialogue to appear, without the warning and timing conditions. Dialogue will be a sort of reverse Exit Guard, and allow cancelling, but the primary function is to resume work, which resets the timer. If you don't touch a button on the dialogue, it has an internal secondary timer, so after a brief time, the session is lost. At this time, a modal dialogue will appear briefly to tell the user the session has ended, then the system will return to it's idle state, or exit (to the idle screen) entirely, depending on the behavior of the system. |
|
| Line 31: | Line 34: |
| If anything less intrusive than a modal dialogue, it often will not be seen. needs a tone or vibrate (COPY OTHERS) for most cases. Countdown in annunciator or otherwise in the corner, for very time-sensitive, hi security systems... |
Problem
High security systems or those which are publicly accessed and are likely to be heavily shared (such as kiosks), must have a timer to exit the session and/or lock the system after a period of inactivity.
Solution
Try to avoid the use of timeout as a solution to load and security. Affinity based load balancing is the default due to simplicity with sharing user data, but requires session-startup processes or leaving overhead for all predicted users for a particular server. There are other methods, so if system and data design is within scope of your project, consider these as part of the overall experience design.
If sessions must expire due to the method by which they have been built already, consider making this transparent. Keep a log of the last-used location in the system, and when the user initiates new activity, resume at that state.
Mobiles are personal, so there is generally less worry about security of individual applications than on the desktop web, or for kiosks. Do not use old-school security practices by default, and only use when needed.
If session expiry is required for security purposes, try to work around it using sensors to detect when a user leaves or puts the device down for some time. Timeout dialogues are based on desktop paradigms, where the computers do not have sensors.
When a strict timeout is needed, a modal dialog appears describing the impending loss of session and presenting methods to preserve the session. When expired, additional information will be presented, and the user will be required to sign on again.
Variations
VARIATION: A more strident alert appears very soon before the session timeout.
VARIATION: FOr secure systems, such as banking, an internal timer may require entering part of the credentials (e.g. a PIN) again if the Pop-Up appears, or after it has been up a short time; the implication is that the original user has stepped away, and this helps prevent unauthorized use.
ALSO: you can have a timeout counter, before it gets critical. In the masthead or footer, where it is not intrusive. Not all the time, but when the time gets shorter. Appearance (vs. always being there) may cause the user to notice. Appears a few minutes before timeout, but timing is very dependent on the user, task and environment.
Interaction Details
SENSORS: Cameras can to detect if the user has left, or changed (or for mobiles, if the device has been set down and is not being used at all). Motion sensors, etc. can tell if the device was left alone; coupled with no input, this can cause a "session timeout" dialogue to appear, without the warning and timing conditions.
Dialogue will be a sort of reverse Exit Guard, and allow cancelling, but the primary function is to resume work, which resets the timer.
If you don't touch a button on the dialogue, it has an internal secondary timer, so after a brief time, the session is lost. At this time, a modal dialogue will appear briefly to tell the user the session has ended, then the system will return to it's idle state, or exit (to the idle screen) entirely, depending on the behavior of the system.
Presentation Details
If anything less intrusive than a modal dialogue, it often will not be seen.
needs a tone or vibrate (COPY OTHERS) for most cases.
Countdown in annunciator or otherwise in the corner, for very time-sensitive, hi security systems...
Antipatterns