Differences between revisions 1 and 2
Revision 1 as of 2010-11-03 21:32:57
Size: 2264
Editor: shoobe01
Comment:
Revision 2 as of 2010-11-03 21:33:24
Size: 2434
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 22: Line 22:



== Problem ==


== Solution ==


== Variations ==


== Interaction Details ==


== Presentation Details ==


== Antipatterns ==


== Examples ==

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: 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...

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.

3) If you have to have it: A modal dialog appears describing the impending loss of session (and why, e.g. security or availability).

If anything less intrusive than a modal dialogue, it often will not be seen.

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.

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.

Problem

Solution

Variations

Interaction Details

Presentation Details

Antipatterns

Examples

Timeout (last edited 2013-04-11 00:01:47 by shoobe01)