Change 785201 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] ProgressBar, Menu, TypeaheadSearch: Add inline progress bar

https://gerrit.wikimedia.org/r/785201

To test, visit the demo site, then throttle your connection (in Firefox, you can go to the Network tab in the inspector and change "no throttling" to something slower). Start typing something in one of the demos. I noticed that the first search sometimes happened quickly, but subsequent searches were much slower.

Some notes on the initial implementation of this:

• General UX: are there any improvements we could make to make the UX feel less jarring, or does this feel ok? This is especially pronounced when the search takes just a bit more than 0.5 seconds to complete.
• Delay: at first I suggested a 1-second delay before we show the pending state, to ensure (as Sarai recommended) that it's only displayed to users with slower connections (no need to show it for a split second for users with faster connections). However, it seemed pretty jarring to wait for a second then see the pending state, so I reduced the delay to 0.5 seconds. Feedback is welcome here.
• What to do when there's no pending message: Right now, if you don't populate the search-results-pending slot with a message (e.g. "Loading search results..."), when you search, you see the UI below. I can add logic to only set pending to true, when this is the initial search, if the slot is populated, but that's going to be kind of gross so I wanted to check first.

• Configuration: How much of this should be configurable for TypeaheadSearch? Things that we could make configurable:
  • Whether or not to enable this behavior at all
  • Delay for showing pending UI

Hey @AnneT. I just saw your comment now, sorry about that. I checked the inline progress bar patch and realized that implementation and design are not aligned, but I think that the coded version is actually more consistent and would like to iterate on the designs based on it. There are just a couple of adjustments needed in the code that would make the variant satisfy the inline use case a bit better, without creating a big departure from the parent component (like the original designs did). Let me know if the following changes make sense to you:

1. Back and forth v. linear movement: In the original demo of the inline indeterminate progress bar, the bar moved back and forth within its container. This makes sense in small spaces with short loading times, where the only loading indicator should remain visible for as long as loading lasts. I think that the linear movement displayed by the coded variant makes it more consistent with the parent version, and thus I would keep it. But, in order to avoid generating any confusion, we could adjust the behavior a bit. Suggestion: Make clear that loading is still going on by reducing the waiting time between bar iterations. This would basically involve adjusting the value of the translate() in the 100% keyframe of the cdx-progress-bar_bar... animation to 250%;.

2. Vertical position: Adding spacing at the top of the bar only made sense when combined with the back and forth animation of the rounded bar. In this version, I think we should remove the 2px spacing at the top.

3. Width: right now, we're applying a 40% width to the bars, which is not part of the spacing scale/tokens. I think that, instead, we could apply a width of 50%, which we'll be able to replace by a token soon.

Re: points 1 and 3, I'm assuming we'd need a separate ticket/patch for this, since the modification applies to the parent component.

Regarding your questions specifically:

General UX: are there any improvements we could make to make the UX feel less jarring, or does this feel ok? This is especially pronounced when the search takes just a bit more than 0.5 seconds to complete.

I'd say that the changes suggested above might improve the UX a bit. If that's not the case, there are a couple of things we could try: 1. It might sound contradictory, but decreasing the animation duration to 1.6s (a system value) might improve things: it's just weird to sometimes only see one iteration of the bar, as it hardly conveys a sense of loading. 2. Adding a background color (Accent90) to the loader track. But, as mentioned, let's take one step at a time.

Delay: It seemed pretty jarring to wait for a second then see the pending state, so I reduced the delay to 0.5 seconds. Feedback is welcome here.

I think 0.5 seconds hits the sweet spot!

What to do when there's no pending message: Right now, if you don't populate the search-results-pending slot with a message (e.g. "Loading search results..."), when you search, you see the UI below. I can add logic to only set pending to true, when this is the initial search, if the slot is populated, but that's going to be kind of gross so I wanted to check first.

I think this adds a +1 in favor of skeleton loading (not yet a system pattern). Increasing the height of the empty menu would probably make this state look less broken, but it's definitely not the right solution. I can't think of a better option other than adding that logic, unfortunately.

Configuration: How much of this should be configurable for TypeaheadSearch?

Just my take, but probably this behaviour shouldn't be configurable – at least initially. Patterns like this are only introduced to improve the user experience, and we shouldn't discourage their application. I'd say that any needed improvements or adjustment should be applied to and from the core component.

Thanks @Sarai-WMDE! All of your comments make sense and I'll make some updates to the patch that adds the inline variant, as well as the patch that adds this to TypeaheadSearch.

edit: As Sarai suggested above, we'll open a separate task for items 1 and 3 in her list, and will tackle them separately once they've gone through design review.

Change 785201 merged by jenkins-bot:

[design/codex@main] Menu, TypeaheadSearch: Add inline progress bar

https://gerrit.wikimedia.org/r/785201

edit: As Sarai suggested above, we'll open a separate task for items 1 and 3 in her list, and will tackle them separately once they've gone through design review.

A separate task collecting the needed adjustments was created: T307456: [Indeterminate InlineProgressBar] Adjust behavior of indeterminate ProgressBar to improve inline indicator. Please note that some of the values suggested originally (in the comment above) changed based on discussions. The new task should now be the source of truth of these requirements.

All looking good. The inline loading bar is correctly displayed when and where specified in the ticket. The task can be signed off from a design perspective.

Regarding:

We might want to add something similar to Lookup and demonstrate how the pending feature within Menu can be used in other components.

Before adding this to the demo, we'll need to align on the pending/loading design pattern we want to apply to "typeahead" elements. Right now, the Lookup's input displays its own loading/pending pattern, which might either be deprecated in favor of the menu's inline bar, or combined with it. In any case, the issue hasn't been properly addressed yet (ticket to be created).

Awesome!