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

When an explicit timeout warning or notice must be presented to the user, there are several states and variations:

When the session expires, a Pop-Up will appear that states the session has expired. Depending on the needs of the system (load or security) the session may be restarted from the dialogue, or dismissal may send the user to a Sign On screen to re-authenticate.

An alert may appear before the session timeout. This may be very strident, such as a Pop-Up or may simply be a countdown in the title bar or corner of the screen.

There may be multiple levels of timeout for security. For example, a banking application may require entering the passcode again when the first timeout is passed, but when a second longer period of time has passed, the complete credentials must be re-entered. These are mostly used on shared systems, like kiosks, to prevent access by others when the original user has abandoned the session.

If secure information is on the screen when a timeout occurs, it may be necessary to obscure the information behind the notification dialogue to assure that no unauthorized users can see the information.

Interaction Details

Determining the appropriate timeout requires careful consideration of the user's tasks, their context and the complexity of their interaction and entry of information for a screen, state or process. Some guidelines for cognitive load are available, but often the best case is to simply test, even with other employees, to get a sense of the time required to comprehend and enter information.

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.

Blanking to obscure data... must look in context usually, so just messes up the screen with a pattern so secure data cannot be read... may be enough to have a large pop-up that obscures all secret information...

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

Antipatterns

Do not let system or load calculations determine acceptable timeout. Often, this will be the driving requirement after all, but fight for a user-based method of determining the correct timing.

Do not use desktop security models to determine timeout for mobile or kiosk-based systems.

Do not ever permanently expire the session without warning the user at the time the session expires. Else, the user will attempt to continue entering information, and will receive an error message, and probably loose their entered information. This can be difficult for web applications on many current mobile browsers, due to Javascript limitations, which is a key reason to consider other methods such as automatic resumption of session.

When complete session expiry must occur, be sure the subsequent pages presented are useful and lead the user back into the system. Do not load full-screen errors, or the site home page. When requiring Sign On, use the identified user information when permitted by security.

Continue presenting useful information throughout the expired session process. Once re-authenticated, return to the last location in the system, not to generic start pages or error pages due to loss of session identifiers.

Do not over-protect information. Portions of an application may have different timeout policies based on varying levels of security. Very rarely does information on the screen need to be obscured; transactional protection is much more common.

Examples