}}}
== Problem ==
When designing high security systems or those which are publicly accessed and are likely to be heavily shared (such as kiosks), you must include a timer to exit the session, or lock the entire system after a period of inactivity.
Timers and sensors are not available for some programming platforms and many web browsers, so may limit the ability to offer a good experience for some users.
{{attachment:Timeout-Process.png|When a period of inactivity is detected, either by simple timer on screen interaction, or due to sensors not detecting use of or proximity to the device, a Timeout notification is presented and the session may be terminated.|align="right"}}
== Solution ==
Many websites or web services use session timeout as a cost-saving measure, to reduce load. 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.
Mobile interaction, even with websites, may be interrupted more than desktops so should avoid such behaviors. 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 your 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. Strict 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.
{{attachment:Timeout-Detail.png|Session and security details should not be routinely shared, mostly to avoid confusing the user. Describe the condition in clear, understandable language, and provide unambiguous, free-standing choices.|align="right"}}
== Variations ==
When you must present an explicit timeout warning or notice 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.
You may want an alert to 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.
{{attachment:Timeout-Countdown.png|It may be useful to include a countdown timer as the timeout approaches. If the user is otherwise aware of the consequences, or there is room to tell them what will happen, this may help prevent inactivity before the Timeout Pop-Up is presented.|align="right"}}
== 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 run a test, even with your friends or with other employees, to get a sense of the time required to comprehend and enter information.
Mobile devices should use sensors to replace or supplement timeout. If you have access to a camera, it can be used to determine if a user leaves even a fixed device like a kiosk. Face recognition is now available, and can already just barely be used to determine if a particular user has likely left the field of view, or more than one person is in view of the screen. Shoulder surfing can be prevented by displaying alerts when more than one user can see the screen. For portable devices, like handsets, timeout can be based on time the device is left unattended, by accessing the accelerometer information. 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, as described in '''[[Cancel Protection]]'''. 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 your security policy.
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.
{{attachment:Timeout-Signon.png|The Timeout notice may also carry other useful information or processes, such as directly allowing re-authentication. Be careful to not provide too much information, or too many choices and confuse the primary message.|align="right"}}
== 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 describe the specific reason such as "Locked due to inactivity," or "Since you walked away…" Emphasize security, and never admit other issues such as load, or discuss a session.
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 often 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, or follow the practices of other products, 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. You should consider giving different portions of an application 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.
----
Next: '''[[Revealing More Information]]'''
----
= Discuss & Add =
Please do not change content above this like, as it's a perfect match with the printed book. Everything else you want to add goes down here.
== Examples ==
If you want to add examples (and we occasionally do also) add them here.
== Make a new section ==
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.