benwakefield commented 6 years ago

Indeterminate progress indicator

Non-repudiation (Internal Service)

Overview

Provide feedback to the user that a process is actively in progress and should be concluded shortly.

animated-ellipsis-screenshot

<div id="retrieving1" class="panel result-progress toggle1 show" aria-busy="true">
 <div class="info">
 <p class="event-record lede">Retrieval may take up to 5 minutes</p>
 <div class="busy" aria-hidden="true"><span>.</span><span>.</span><span>.</span>
</div>

.info {
  display:block;
  .event-record.lede {
    display:inline
  }
}

.busy {
  display:inline;
  span {
    font-weight:bold;
    margin-right:0.125em;
    animation-name: processing;
    animation-duration: 1.4s;
    animation-iteration-count: infinite;
    animation-fill-mode: both;
  }
  span:nth-child(2) {
    animation-delay: .2s;
  }
  span:nth-child(3) {
    animation-delay: .4s;
  }
}

For users with mobile accessibility preferences set to Reduce motion:

@media screen and (prefers-reduced-motion: reduce) { }
@media screen and (prefers-reduced-motion) { }

 .busy span {
   animation-play-state: paused;
 }

Is it useful and unique?

There are no patterns for in progress indicators
Indicates that a process is actively in progress and should be finished in a relatively short time

GOV.UK Design System criteria

Simple solution
Tested positively with users that something was actively happening
Testing demonstrated that our internal users expect more feedback when delays are encountered
There are no patterns for this feedback function
A progress bar indicator which is currently being tested (Beta) is used for dynamic, determinate progress situations, we cannot provide determined (dynamic) progress for technical reasons.
Ellipsis natively implies that something is unfinished / incomplete
Animation created with CSS which degrades gracefully
Can be marked up semantically
Complies with WCAG guidelines
Can be given context and styled easily with preceding inline message
Is not bitmap based

Other components or patterns you've tried

There are no progress indicators patterns. There is a determinate progress bar pattern currently in testing however this cannot be used as we are unable to establish the length of processing time (only that the wait could be up to 5 mins)

Research on this pattern

User need When retrieving information from the store I need system feedback so that I know my request is in progress

After the user runs a search on a tax identifier, submission results are returned from short term storage. From these (instant metadata) results a linked original record could be retrieved from long term storage. This creates a break in the user journey which we need to bridge with system feedback. We identified 4 UI states from point of search results to the record being downloaded.

1 of 4 - Retrieval (metadata search results returned from short term storage - CTA to retrieve) 2 of 4 - In progress (Request sent to retrieve original submission from archive - up to 5 mins wait) 3 of 4 - Ready (Original submission ready for download) 4 of 4 - Downloaded (UI feedback showing which records have been downloaded)

Usually the user would not expect to separately action a retrieval request, then download once the file had been returned from archive. This cognitive disconnect caused us to experiment with an indeterminate progress indicator which helped the user understand what was happing and that a waiting time was normal.

State 2 and 3 have to be actioned independently otherwise we’d effectively be asking the browser to download a file without explicit user consent which is a security risk.

Usability testing Round 7 Findings and Usability research R8 in the Non-Repudiation Home space in Confluence.

Gaps We observed in subsequent usability testing that the UI progress feedback reduced confusion and frustration regarding why a record had to be actively downloaded after waiting for it to be retrieved. It helped mitigate the extra stage in the retrieval journey.

We only prototyped with the animated ellipsis as a starting point however it is a simple and accessible solution to help resolve the need to provide in-progress system feedback.

stevenaproctor commented 6 years ago

Discussed at working group on 9 March. It was considered to be useful and unique but with some questions about implementation. These were about the accessibility of the indicator and providing feedback to all users and the content, "retrieval" and "retrieve", in the example.

benwakefield commented 6 years ago

Can you provide more details on the accessibility questions you have so we can focus further testing. The content "retrieval" and "retrieve" were provided for context only, it was not part proposal / issue raised.

stevenaproctor commented 6 years ago

@adamliptrot-oc Would you be able to summarise the accessibility issues? I know you had concerns about hiding the indicator from a screen reader user and not giving them an indicator that something was happening.

benwakefield commented 6 years ago

The containing state div was marked up: <div... aria-busy="true">

This should indicate that the overall in-progess state was busy doing something.

Have included full code snippet in original information

adamliptrot-oc commented 6 years ago

Aria busy is probably the wrong attribute to use in this case - aria busy is normally used where you don't want the user to interact with the element/widget until it has finished loading. In this case we want to tell the user the file is being retrieved. Some assistive tech might not expose the element while it has the busy state. I'd suggest using an aria live region. In the example above the changes would not be announced. It would be possible for the user to kick-off several files retrieval and being alerted as to which are ready to download is important. The region would also need to include the name of the file so when the state changes the file name is included in the announcement (the file name doesn't have to be displayed but should be available to the screen-reader).

enoranidi commented 6 years ago

Hi @adamliptrot-oc, apologies first for not replying back to your response.

So in the original div we have:

<div id="retrieving1" class="panel result-progress toggle1 show" aria-busy="true">
    <div class="info">
        <p class="event-record lede">Retrieval may take up to 5 minutes</p>
        <div class="busy" aria-hidden="true"><span>.</span><span>.</span><span>.</span></div>
    </div>
    <p class="filename">Original_VAT-return_12-15_ABC-Accounting_987654321.ZIP</p>
    <p class="font-xsmall">Submitted on 1 Jan 2016</p>
</div>

where <div... aria-busy="true">

But to use aria-live (based on your suggestion) is this correct?

<div id="retrieving1" class="panel result-progress toggle1 show" aria-live="polite">
    <div class="info">
        <p class="event-record lede">Retrieval may take up to 5 minutes</p>
        <div class="busy" aria-hidden="true"><span>.</span><span>.</span><span>.</span></div>
    </div>
    <p class="filename">Original_VAT-return_12-15_ABC-Accounting_987654321.ZIP</p>
    <p class="font-xsmall">Submitted on 1 Jan 2016</p>
</div>

The div also contains the filename as well - which you mentioned.

Would it also be beneficial to add aria-atomic="true" after aria-live?

stevenaproctor commented 6 years ago

@JSJohal Here is the progress bar I mentioned today. It is not really a progress indicator but may be of some help.

employment-intermediaries