Guidance on using progress bar vs. skeleton loader

[vanesng]

Hi there,

My team is building a feature which allows users to preview counts & the list of users while building an audience – Between the progress bar and skeleton loader, which component do you recommend using for the loading state of the preview for this scenario?

More details below:

• From eng on how long preview will take to load: "We have little idea, but I expect it to be somewhere in the 20 seconds to 1 hour range depending on how large the customer's warehouse is"
• I'm leaning towards option 1 (determinate progress bar) to give users a sense of progress, even though we technically don't know how long loading may take
• Could it be an option to start with the determinate progress bar, but an some threshold (maybe 2 mins), switch the progress bar's state to be indeterminate? We will probably timeout the preview from loading at the ~1 hour mark (to be decided with eng).

Thanks in advance!

[TwilioPasteBot]

Disclaimer: This is a very experimental bot using OpenAI's GPT-4. The answers may not be correct, a human will review the answer and update it if necessary.

---

Based on the information provided, it seems like the Skeleton Loader would be the best fit for your use case.

The Skeleton Loader is designed to improve perceived performance and user experience by reducing load time frustration and making the page feel more responsive. It's an alternative to the Spinner component and is used in place of the content being loaded.

Here's an example of how you can use it:

import {SkeletonLoader} from '@twilio-paste/core/skeleton-loader';
import {Text} from '@twilio-paste/core/text';

const SkeletonLoaderExample = () => {
  const [loaded] = React.useState(false);

  return <>{loaded ? <Text as="span">Single line of text</Text> : <SkeletonLoader width="100px" />}</>;
};

However, if you want to provide a sense of progress, you could consider using an indeterminate Progress Bar. An indeterminate Progress Bar is used when progress is being made, but you can't calculate how much progress or you don't know the value.

Here's an example of how you can use it:

import {ProgressBar, ProgressBarLabel} from '@twilio-paste/core/progress-bar';
import {Box} from '@twilio-paste/core/box';
import {HelpText} from '@twilio-paste/core/help-text';
import {useUID} from '@twilio-paste/core/uid-library';

const AlertDialogExample = () => {
  const progressBarId = useUID();
  const helpTextId = useUID();

  return (
    <Box>
      <ProgressBarLabel htmlFor={progressBarId}>Downloading more RAM</ProgressBarLabel>
      <ProgressBar id={progressBarId} aria-describedby={helpTextId} isIndeterminate />
      <HelpText id={helpTextId}>Increasing your RAM helps your computer run faster.</HelpText>
    </Box>
  );
};

Switching between a determinate and indeterminate state is not explicitly mentioned in the documentation, so it's unclear if this is a recommended practice.

---

Here are some similar discussions:

• Skeleton Loader (updated: 2022-05-20T17:03:27Z, similarity score: 0.86)
• Request for comment (RFC): Progress Bar (updated: 2023-10-05T17:00:55Z, similarity score: 0.85)
• Toggle and stepper/Progress bar (updated: 2022-06-14T21:00:04Z, similarity score: 0.85)

[SiTaggart]

Close Pastebot, close.

[SiTaggart]

Hi @vanesng

We think ultimately the answer is going very dependent on what is feasible from an engineering perspective.

If you can detect with accuracy the actual progress, even if it's taking a super long time, you should use a Progress bar with a determinate state.

If you cannot determine the progress of the process, then you should only use the indeterminate state of the progress bar.

In both cases, some excellent help text explaining that it can take a long time depending on the size of the data set will go a long way to explaining the situation.

Skeleton loaders should really only be used in page or content loading situations to improve perceived page load performance. It's not designed to communicate progress or the state of a process. It's effectively not there

[serifluous]

Here's a reference article for app response times longer than 10 sec: https://www.nngroup.com/articles/response-times-3-important-limits/ They recommend a "percent-done indicator".

If it's going to be a pretty common siuation that the wait time is over even 30 sec or a minute, you might want to do some more explorations on this part of the flow, and let users be notified when their preview is ready, rather than have them wait on the page.

[vanesng]

Sounds good, this is helpful. Thanks both!