I feel that the skeleton state happens before we can confirm if semantic search can happen or not, and therefore, unavoidable. Would like to double check this with engineer, and I also have a proposal for a third path that would improve user experience with a probable low lift (I think?) - video with those items for discussion so we don't forget: https://drive.google.com/file/d/1b-_4xC5nWc6mTKwBEGrh35_-5bUKc9q2/view?usp=drive_link

Could we use an alternative progress indicator using material design for the sake of the MVP? For example this one that uses Jetpack compose? That seems like the easiest route. Another possible path is show the full skeleton, if retrieval fails, remove the semantic section skeleton after a short delay, then remove the section completely I don't think we should expand the list of lexical results, I think continue to show 3 lexical results (if they exist).

I also want to point out the section below that says "run a deep search" is a nice to have so there is a world where that section doesn't exist or the copy is different like "search for pages containing...." to mirror web.

Its also note worthy that that our existing loading indicator for search is the linear progress bar and if there isn't coverage for lexical users will see "no results".

Thanks for the comments above, Jaz - yep, I am aware that our existing loading indicator is the linear progress bar. My suggestion of skeleton loading is due to the constraint that we may face regarding the latency of the semantic search. Skeleton loading states are proven to reduce perceived delays, so the user experience is smooth, minimizing the risk of negative impact on user perception and metrics (for example, users feeling that semantic search is slower and therefore disliking the experience).

My recommendations here are:

1. Leave as is - we have a skeleton for deep search, and if it doesn't load, it is okay - this state should be fast (hopefully), this is a rare scenario users will face, and it is also common on apps that the skeleton doesn't match 100% of the upcoming UI. This is already designed and ready to go. I would like to still advocate for the toast to communicate to users that the experience isn't a full one. This encourages them to try new queries and experience the semantic search, which is aligned with our goals.

2. If the skeleton is a heavy lift for the MVP and we are okay with the risk of perceived slowness of the semantic search experience, we can remove the skeleton and use our existing loading indicator, as you suggested. The toast is still beneficial to this scenario. I can design this one since it isn't ready yet.

Sure, if you can format the file and leave the link for the first recommendation without the toast. The second recommendation with a toast. And a best case scenario as described in the task.

Here they are:

1. Indeterminate progress bar flow with no toast (Figma link)

2. Indeterminate progress bar flow with toast (Figma link)

3. Skeleton state with toast flow (Figma link)

{F71147307}

4. Skeleton state with empty state message flow (Figma link)

Thanks for doing this. The third file appears to be locked, you may have to edit the task and unrestrict the file for us to see it @TLessa-WMF

Thanks for letting me know! Odd, I can't reproduce that - checked the links and access...we can troubleshoot that once we meet again - worst case I can duplicate the file and try to share again.

If we implement the "nice to have", we will need to better understand the possible errors so we can communicate those states to users:

1. When semantic retrieval fails (empty results, error response, or below-confidence threshold) - we can say something like "Something went wrong. Please try again later."
2. If no coverage for the topic we can use the copy: "This topic isn’t supported by deep search yet.
Here are some things you can try: Rephrase your search / Try a related topic [Learn more]
3. Any others?

Williamrai opened https://github.com/wikimedia/apps-android-wikipedia/pull/6274