New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timeout warning #104

Open
govuk-design-system opened this Issue Jan 15, 2018 · 4 comments

Comments

5 participants
@govuk-design-system
Collaborator

govuk-design-system commented Jan 15, 2018

What

Warn users that their session is about to time out and let them extend it if possible.

Why

All services that use sessions already use, or should use this pattern.

Anything else

Related patterns

#103 Timeout page

@ignaciaorellana

This comment has been minimized.

Contributor

ignaciaorellana commented Feb 20, 2018

I had a chat with @hannalaakso and the example component still needs to be separated into: Timeout waring & Modal Dialogue (aka Modal window, pop-up). We recommend for now to look at both issues in the backlog.

@hannalaakso

This comment has been minimized.

Member

hannalaakso commented Jun 5, 2018

Draft guidance for Timeout warning (from Draft guidance on Google Docs

Use this component to warn users that their session is about to time out.

A timeout warning helps services meet WCAG 2.0 success criterion 2.2.1 - that services warn users before a timeout occurs and allow them to extend it.

Example:

IMAGE

View a demo of this component

When to use this component

The timeout warning should appear 5 minutes before the timeout is due to occur.

Follow the session timeout pattern to ensure your timeout is well designed.

How it works

After a period of inactivity, the timeout warning is shown the user. The user is given a period of time to take action, with a count down to show amount of time left.

The actions presented would typically be to continue with the application (thus resetting the timer), or a secondary action suitable to the service - such as cancelling the application or saving it.

If the user does not choose to continue the application within the time limit, they will be redirected to a timeout page that explains what has happened and give options for how to continue. The session timeout pattern contains an example of this page.

Services should watch for user activity and extend the timeout appropriately. This is particularly important for services or pages which may take users longer than the timeout duration to complete.

How client side and server could potentially communicate - draft

When the user loads a page, the server records this as the last interaction in the session.
When the user interacts with the page, the client side sends periodic heartbeats (at most every 30 seconds and these should be debounced) to the server which updates the last interaction time accordingly.
When the user stops interacting with the page, the client begins a countdown to 25 mins of user inactivity. Once elapsed, the client checks the last inactive time with the server to verify last active time (user could have been interacting with the page in another window) and opens modal. If user does not interact with the modal for another 5 minutes, client will check last active time with server. If server confirms last inactive time was 30 mins ago, client will redirect user appropriately.
Once the modal is open, the client needs to know if user has closed the modal in another tab.
The inactive time until user is redirected should match session length on server: we recommend waiting 25 minutes until showing the timeout warning and giving users a 5 minutes to dismiss the warning warning.
If user dismisses the modal, client notifies server of new time user was active and server extends session appropriately.
An alternative could be to use local storage to replace some of the server interaction.

Note that this is all hypothetical and probably too much detail, the service team should consider what works best for them.

Progressive enhancement

Users who have JavaScript enabled can extend their session. This is progressive enhancement since it is possible for users without JavaScript to use and interact with the service.

No JavaScript solution

For situations where the user does not have Javascript, the service should:

Tell user by which time they'll need to have completed the form (include name of timezone) and hide this message with JavaScript.
Use a meta refresh tag inside Noscript tags that matches the session timeout time (Unfortunately Noscript won't catch users whose JavaScript has been blocked by a firewall but there is no way to reliably way to remove the meta tag across browsers with JavaScript: the header is not part of the DOM and the browser will process the meta tag on page load).
If user does not submit the form by the specified time, meta refresh will take them to a timeout page.

The following enhanced solution where user is able to extend their session without JavaScript was discussed but was deemed to add too much complexity:
Have an Extend session button on the page. Extend session button will submit the form and refresh the page. It resets the session on the server and prints out the new timeout time on the page. No validation and saving of data in the database should happen.

Accessibility
Having a timeout warning helps services meet WCAG 2.0 success criterion 2.2.1 - that services warn users before a timeout occurs and allow them to extend it.

Services should not limit the number of times users can extend their session.

In addition, the timeout warning:
Announces the remaining time to assistive technology (using less frequent intervals than the visible countdown)
Makes the underlying page content non-actionable and non focusable.
Content variations
Services will require at least two versions of content for the timeout warning (and subsequent timeout page).

These are:
warning shown during application
warning shown after completing application

The first will warns that users will need to start again, whilst the second should advise how users can track / get more information about a completed application.
Services with sign-in / accounts
Services will need to vary the content if they have account functionality or otherwise save user data.

Research on this component

We carried out research lab sessions in autumn 2017 with various different types of users.

Findings:
Users have high awareness of timeouts and timeout warnings
Users will often dismiss / acknowledge the timeout quickly without reading the content
Users were often unaware of the secondary option as they closed the warning so quickly.

Devices tested on - Draft

Chrome, Firefox, Safari (desktop) - latest version at the time of writing
Internet Explorer 11
Microsoft Edge 14, 15
Android Galaxy S8, Pixel 8, Nexus 7: Chrome and Firefox
iPhone 6, iPhone 5s: Safari, Chrome

Accessibility

AT technology that the component has been tested with:
Jaws 14/15 + IE11 + Windows 7
Jaws 17/18 + IE11 + Windows 10
NVDA + Firefox (latest version at time of writing) + Windows 10
VoiceOver + Safari + iOS 10.3.2 + iPhone 5s
VoiceOver + Safari + Mac OS 10.11.6
Dragon NaturallySpeaking 13

On AT, the timer updates every 15 seconds. These timings are currently being reviewed by the GDS accessibility team.

We have written accessibility acceptance criteria that was reviewed by GDS Accessibility team:
https://gist.github.com/hannalaakso/2641fc16d2158e60d551cd9da960b5da
The component currently fails number 7 as no browser supports this.

List of accessibility attributes on the component:

Attribute and value HTML element Reason for using
aria-live="polite" modal-dialog When AT reads content, modal content does not interrupt other content
aria-labelledby=”dialog-title” modal-dialog Heading is read out by AT
aria-describedby="at-timer" modal-dialog Timer is read out by AT
role="dialog" modal-dialog Ensures backward compatibility if no browser support for “dialog” element.
role="status" at-timer Timer is read by AT on iOS VoiceOver
aria-hidden="true" timer Element is hidden to AT (Instead, AT reads out “at-timer” that updates less frequently)
aria-relevant=”additions” timer There is a bug in Jaws 17/18: it ignores aria-hidden and reads out contents of element. This is a hacky solution to get around the issue. The bug has been reported to Freedom Scientific.

More research needed to find out:

The steps leading to the appearance and dismissal of the modal when user has site open across multiple tabs, see card
Where exactly users look on the timeout modal to determine what type of content they are likely to read; we would like to test this with an eye scanner.
User behaviour with other type of content than a timeout, for instance a warning not to enter personal sensitive information, or a form inside the modal.

User research on Timeout warning (from User research on Google Docs

Timeout warning findings

Overview
We have been testing a group of components and patterns as a project in the Design System team. In here we discuss the work and findings for the timeout warning component.
You can read a project summary here which will explain in more detail about the work we did and the team behind it.

We tested timeout warning with 17 users in total.
Session 1 and 2: 7 users that confident or expert level digital users
Session 3: 7 users that are low confident digital users
Session 4 and 5: 4 users with access needs

You can find the guidance document for timeout warning here
About timeout warning
We are building a modal dialog with a timeout warning. Also referred to as ‘session timeout warning’. It is basically a message that comes up on the screen after the user has been inactive for a period of time and warns them that their application or session will be timed out. It then should give the user a few options like continue with their application or perhaps cancel the application.

We tested with three different options presented for the users:
Continue with the application
Cancel the application
Save application

Example

Why a modal dialog?
Modal dialogs - better known as popups - are a window that appears on the screen and requires the user to interact with it before continuing. There’s a lot of guidance and discussion around modal dialogs and when not to use them.

But they are useful when you need the user to focus on one task and one task alone. Often they are used to inform the users about something important that needs an action from them. For example, a good use case of modal dialogs could be divided into after two different types.

The first type is when the user by an action has triggered it. For example this could be after the user has clicked on closing or deleting something.

*** Replace with Gov example?

And the second type is what we’ve been working on for the last couple of months - a timeout warning modal dialog that only comes up if the users has not performed any actions on the screen for an extended period of time.

Our findings

1st version

We set this to appear after two minutes of inactivity, which we obviously understands is a very short and unrealistic time, but for the purpose of testing the component we felt it was fine.

Instant but correct reactions?
We learned from the first two research sessions that most users responds to close down the timeout warning very quickly when it appears on the screen. All of the users that showed this behaviour did click on the green ‘Continue application’ button which was positive and indicated that they did understand what the modal dialog was.

We also asked the users at that point or when it appeared later on what their understandings was about the modal dialog, and what their options were. When asked they all responded that the timeout warning had appeared to them not being active on the application. So in all cases it validated that they understood what it was for and why it had appeared on the screen.

Mixed understandings
We did however see some mixed results about the understanding of what options they had available to them when the modal dialog appeared. Most of them were quick to close down the modal dialog and didn’t take time to look at what was said on it or knew if they had another option to click on.

When asked what would have happened to the information that they had already filled in if their application would have been timed out it appeared that not all users understood that their data would have been lost if they didn’t click on ‘Continue application’.

This had us thinking, did the user really understand what their options were? Could we test this by adding another option on the modal that they could interact with?

So we decided to tweak our component slightly and remove the ‘Cancel application’ button and instead replace it with a ‘Save application’ button instead. This was something a couple of the participants had also mentioned themselves during the session as something they’d like to have seen.

2nd version

Users didn’t click on ‘save’
It was expressed by several users during the testing that a save feature would have been useful. This was shared amongst several users when discussing how they would have felt about losing the data they had filled in. But what became clear in the last rounds of research that only two user out of 15 did actually click on the ‘save’ link in the end.

Users seem clear that it’s for security reasons
What was clear for most if not all users when asked about it, is that they knew that timeout warnings and taking users out from a service journey if they still idle for too long, is that it’s for security reasons. Which was really positive to hear. They might find features like this too be very annoying (using their own words) but they understand that it’s there to protect their data.

Summary
Users have high awareness of timeouts and timeout warnings
Users will often dismiss / acknowledge the timeout quickly without reading the content
Users were often unaware of the secondary option as they closed the warning so quickly
Conclusion

We assume that the most common scenario for when a timeout warning will appear is if a user has left their computer to do something else. A timeout warning should not appear ifthe user has not progressed through a page after a long time but has still been active on it. For example, if they need to write something that is more complex than selecting a radio button the timeout needs to be longer.

Modal dialogs works well for timeout warnings
One of modal dialogs more common use cases is definitely for timeout warnings. And there are good reasons for it. A modal dialog can easily grab the user’s attention. And from our research we feel confident that modal dialogs serves the purpose of a timeout warning well.

What is a reasonable time limit?
The limit for when a timeout warning should appear needs to be a realistic number. It of course can’t be coming up after just a few minutes like in our research sessions. The limit needs to be set by service teams. But a potentially reasonable limit is between 20 and 30 minutes.

Save and return?
Having a save feature was something many users mentioned as a desired feature. This was very much the case when discussed further with the users about the possibility to be redirected out from a service and losing their data. So if you have a timeout warning feature in your service application it might be a good idea for you to at least explore the idea of having a save and return feature. But this very dependant on the type and length of a service.

Outstanding research required:
Additional testing with assistive technologies - general testing
Dragon

Additional research of interest:
Additional testing with users of various access needs;
Dyslexia, autism
Save and return features

Lab testing

Desktop (windows), laptop (windows), iPhone, Android, iPad
JAWS, Voiceover (iPhone and iPad), Zoomtext 10, physical magnifier

Devices tested on

Chrome, Firefox, Safari (desktop) - latest version at the time of writing
Internet Explorer 11
Microsoft Edge 14, 15
Android Galaxy S8, Pixel 8, Nexus 7: Chrome and Firefox
iPhone 6, iPhone 5s: Safari, Chrome

Accessibility

AT technology that the component has been tested with:
Jaws 14/15 + IE11 + Windows 7
Jaws 17/18 + IE11 + Windows 10
NVDA + Firefox (latest version at time of writing) + Windows 10
VoiceOver + Safari + iOS 10.3.2 + iPhone 5s
VoiceOver + Safari + Mac OS 10.11.6
Dragon NaturallySpeaking 13

@ignaciaorellana

This comment has been minimized.

Contributor

ignaciaorellana commented Jun 5, 2018

that's amazing @hannalaakso thanks for this!

@nickcolley

This comment has been minimized.

Contributor

nickcolley commented Oct 18, 2018

The new WCAG 2.1 (Level AAA) guidelines specify that: "Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions."

https://www.w3.org/TR/WCAG21/#timeouts

@stevenaproctor stevenaproctor referenced this issue Nov 26, 2018

Open

Service timeout #175

0 of 5 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment