| • Sarai-WMDE | |
| Jun 8 2022, 5:06 PM |
| F35281352: image.png | |
| Jun 27 2022, 5:47 PM |
| F35250084: T310200 MenuItem placeholder loading screencast 2022-06-17.mp4 | |
| Jun 18 2022, 12:53 AM |
| F35219419: image (1).png | |
| Jun 8 2022, 5:06 PM |
| F35219431: Screenshot 2022-06-08 at 19.05.54.png | |
| Jun 8 2022, 5:06 PM |
When a search is performed using TypeaheadSearch with a slow connection, menu items display white thumbnails until the available images are loaded.
We should prevent this from happening and, instead, display thumbnail placeholders in all menu items as long as individual images are not available.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Duplicate | None | T299666 Add TypeaheadSearch component to Codex | |||
| Resolved | • Sarai-WMDE | T297025 Add TypeaheadSearch to Codex | |||
| Resolved | • DAbad | T300625 Add MenuItem component to Codex and TypeaheadSearch component | |||
| Resolved | • DAbad | T310200 MenuItem: Display placeholder thumbnails before images are loaded |
Change 805333 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):
[design/codex@main] MenuItem: Display placeholder thumbnails before images are loaded
Looking at the latest patch by @SimoneThisDot (thanks!), the way of exchanging is a simple show hide, which is aligned with the current task description.
Before the patch you've had a skeleton (the box shadow, now border around the thumbnail to be loaded and when it's loaded the thumbnail appears in the given boundary.
With the patch, you have already something sitting there, a relative high contrast-ey element, that suddenly (as in 0 transition) is covered with an image.
See
@Sarai-WMDE In my opinion this should also include a slow transition or fade-in at minimum. In a list of five or more elements where user actually should focus on the search results, the loading behavior of sudden appearance is too distracting for good user-experience.
Thanks for noticing and for the suggestion, @Volker_E. I agreed with @SimoneThisDot that we could introduce the transition as part of this same task, given that the patch is still active.
What kind of transition did you have in mind? Looking at our existing tokens, I think we could apply ease 250ms opacity to the image as it fades in (transition from opacity:0 to 1 on enter). What do you think?
Since we're playing with the opacity of overlapping elements, maybe applying the same transition to the placeholder as it fades out (transition from opacity:1 to 0 on leave) would make things even smoother, but I can't be sure of how noticeable this would really be.
opacity could work, but it would mean that we go from the placeholder image to the thumbnail and it wouldn't always be a nice transition IMO.
If we can set the placeholder to 0 in the beginning of the transition, it would become a smoother transition.
I have updated the patch to now have a transition for 250ms and make sure that the placeholder is hidden at the start of the animation so that transition looks good.
The only thing I noticed is that by showing the same image for both the placeholder and the fallback in case there is no image gives the wrong impression to users..
Example:
From a UX perspective, it seems like the images are still loading because there is no change from a loading state! Any thought?
I see and share the concern you're describing. This approach makes it look like some images are still pending or 'failed' to load. After giving it some thought, though, I'd say we should still go ahead with this solution, because it's at least an improvement (the white squares really made the component look broken).
In a (hopefully) near future, we could iterate on this and maybe use skeleton loaders instead of the thumbnail placeholders. This is a pattern that we'll start exploring for the Card component, and that might be applied to thumbnails on load (see an example of what I mean).
+1 to Simone's concern, and to Sarai's suggestion that we move forward with this solution for the time being.
One thing we could do to mitigate the impact of this is to only show the placeholder to users after a period of time, e.g. half a second. This way users with fast connections would never see the placeholder icons, but users with slower connections would get some kind of signal that thumbnails are loading. This is the same approach we're taking with the inline progress bar in TypeaheadSearch.
I've merged Simone's patch implementing this, but we can revisit the code once we have a standard skeleton design.
Another thing that could use some design review: is the transition a bit too slow for users with a faster connection? It's pretty noticeable, and although it's nice when images are coming in slowly, when they're basically all loading at once it seems unnecessarily slow. Would 100ms be better?
Change 805333 merged by jenkins-bot:
[design/codex@main] MenuItem: Display placeholder thumbnails before images are loaded
Regarding the transition's duration: I'm torn! I've been trying both options and, while I like the smoothness of 250ms, I agree that faster loading transitions always feel more efficient. We also recently increased the speed of progress bar animations, so I think we could follow the trend and apply 100ms here. After all, it's @transition-duration-base 👍🏻
Change 807606 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):
[design/codex@main] MenuItem: Reduce transition duration of thumbnail
Change 807606 merged by jenkins-bot:
[design/codex@main] MenuItem: Reduce transition duration of thumbnail
Thanks so much, @AnneT 💯 I tested the new implementation using the pending state demo in Safari v15.5, Firefox v101 and Chrome v103 on MacOS Monterey. No issues were found: the placeholder thumbnails replaced the white squares and are displayed while images load. Said images display the agreed upon 100ms opacity-based transition on enter. Seeing also that @Volker_E already provided a +2 in the last patch, I consider this ticket can be signed off from a design point of view.
