Differences between revisions 10 and 11
Revision 10 as of 2010-11-09 18:08:12
Size: 9125
Editor: shoobe01
Comment:
Revision 11 as of 2010-11-09 19:54:02
Size: 9137
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{attachment:||align="right"}}
{{attachment:||align="right"}}
{{attachment:||align="right"}}
{{attachment:||align="right"}}
{{attachment:||align="right"}}
{{attachment:||align="right"}}
{{attachment:Timeout-Process.png||align="right"}}
{{attachment:Timeout-Detail.png||align="right"}}
{{attachment:Timeout-Countdown.png||align="right"}}
{{attachment:Timeout-Signon.png||align="right"}}

Timeout-Process.png Timeout-Detail.png Timeout-Countdown.png Timeout-Signon.png

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.

Mobile devices can use sensors to replace or supplement timeout. Cameras can be used to determine if a user leaves even a fixed device like a kiosk. Face recognition is now available, and could also be used for this. Shoulder surfing could be prevented by displaying alerts that more than one user can see the screen. For portable devices, like handsets, timeout can be based on time the device is left unattended. This timing can be very short, since any application requiring this level of security can generally be assumed to take the full attention of the user; if set aside, they may understand the need to re-authenticate to continue.

When a Pop-Up is presented for timeout, this is a sort of reverse Exit Guard. The user will be presented with options to exit, but the primary condition will be to resume work. This will reset the timer, or load a Sign On screen or dialogue as required by security needs.

If the timeout dialogue is not used within a certain period of time, it may have a second timer, after which the system returns to its idle state. This is most used in shared systems, but may be useful for personal mobile applications where the primary function is consumption. The lost data will be saved as a draft message, for example. A notice should appear on this screen somewhere informing the user of the loss of session and auto saving of data.

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.

It may be useful to present the Sign-On information within the Timeout dialogue. Even if technically possible, make sure it is not confusing, and does not exceed the space available. This is a case where tasks may need to be broken up to avoid complexity, even though it will slow down experienced users.

Presentation Details

Timeout is a very critical condition, so must be very clear. Anything less intrusive than a modal dialogue often will not be seen.

The Pop-Up dialogue must be titled and labeled clearly, but with as little technical jargon as possible. Describe the situation not as "timeout" but with descriptive phrases such as "Locked due to inactivity." Emphasize security, and never admit load issues.

Button labels must not depend on the description or title. Never present selections such as "Yes" and "No." At the same time, do not let options be too long, or they may not be readable, or may not look like selections. Typical options are along the lines of:

  • "Continue working"
  • "Exit application"

Though these need to be contextually relevant. "Continue drawing" and "Stop banking" for example. Cancel and close conditions, as they apply to the Pop-Up dialogue do not really apply here. Though the "Continue" label could be replaced with an action to dismiss the dialogue, since it was system initiated, the explicit label is more clear and understandable.

If the user must sign on to continue, do not use generic terms like "Continue working" and state in the description that they must re-authenticate.

If on-screen data is determined to be secret enough it must be obscured during timeout, this may be done by either making the dialogue big enough to obscure all key information, or by using a pattern to darken the screen. A simple 1px checkerboard of clear and black (also an old trick before transparency was common) will reduce legibility of type it is laid across. If still readable, change the scale of the pattern.

Use non-visual methods to notify the user of the stop in process, such as audio and/or vibration. Follow current system volume settings for the notification. Mobiles are used in quick glances, so the user may not notice such a stop in process for minutes or hours unless informed via a non-visual channel.

If the timeout is very short, or when it begins to become very short (under 30 seconds) it may be desirable to add a countdown somewhere on the screen. This must be labeled clearly, the timer should count individual seconds, and it should be slightly obtrusive. Make sure it appears from a blank area, instead of replacing another component; this, coupled with the movement of the clock, should make it reasonably visible.

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.

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

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