Indeterminate progress indicator

[mikeash82]

What

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

Why

• 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
• 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 tried

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)

Anything else

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.

Code

<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;
 }

@stevenaproctor commented on 9 Mar 2018
Discussed at HMRC 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 on 12 Mar 2018
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 on 12 Mar 2018
@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 on 12 Mar 2018
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 on 22 Mar 2018
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 on 4 Apr 2018
Hi @adamliptrot-oc, apologies first for not replying back to your response.

So in the original div we have:

Retrieval may take up to 5 minutes

...
Original_VAT-return_12-15_ABC-Accounting_987654321.ZIP

Submitted on 1 Jan 2016

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

Retrieval may take up to 5 minutes

...
Original_VAT-return_12-15_ABC-Accounting_987654321.ZIP

Submitted on 1 Jan 2016

The div also contains the filename as well - which you mentioned.
Would it also be beneficial to add aria-atomic="true" after aria-live?

[NickColley]

Thanks for putting this together is looks really interesting, I have a question about the accessibility:

Did you test this solution with assistive technologies such as a screen reader, or test this with users of assistive technologies?

I took a look into aria-busy and it looks to be used for letting assistive technologies know that they may not announce the contents since it's busy.

This seems more appropriate for an in-progress rendering of HTML rather than a way to indicate a loading state?

https://developer.paciellogroup.com/blog/2018/05/short-note-on-being-busy/

If this component updates in real-time as the user is on the page, maybe we could consider status live regions or progressbar semantics which would describe the area that is busy.

[joelanman]

Is this the same as loading spinner? This name seems better, but we probably only want one place to discuss, if it is the same user need.

[mikeash82]

I believe they might share the same user needs. @benwakefield what do you think?

[benwakefield]

Sorry for slow response @mikeash82. Yes its a similar need but not exactly. The loading spinner may work ok with single page actions / multiple things updating syncronously - however it tends to fill larger areas of the screen which can prevent users from otherwise interacting with other things on the page.

If you need to represent things which load asyncronously, multiple spinners would be fiddly to implement, particularly responsively, and possibly create cognitive / perception problems.

Providing feedback using the pure css method we can easily add the "..." to whatever info / element we're playing back (which also adopts the parent style). It's less intrusive than the spinner as it only covers a few pixels and meets WCAG, its also more robust as it doesn't need bitmaps and degrades gracefully maintaining its semantics.

[RossGower]

This UI/Interaction is for a specific need where a users triggers a database export from a casework/intel system. Content still needs a bit of work. There are also states for failure