Change 837662 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/SearchVue@master] Set aspect ratio ahead of time & remove fixed heights

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

commented on the wrong story

I updated the description because currently commons images are not loaded with the correct width and height while loaded. This can be improved.

Change 837662 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Set aspect ratio ahead of time & remove fixed heights

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

Change 849048 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[mediawiki/extensions/SearchVue@master] Loading content in Search Previews

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

@Sneha: that last screenshot shows the loading indicator below the Commons widget (which is already rendered, but doesn't show the images yet)
What is the reason for showing it there at that point?

• Because there will (at some later point) be additional content below there (interwiki results), or
• Because we want the loading indicator to stick around until all Commons images have been loaded (even though we already render the widget with grey placeholders)?

Asking because I think in the case of #2, it may trick people into thinking expecting even more content to come at some point (because they're already seeing that there will be images)
Also because it could become a little tricky to coordinate - e.g. should we also keep the loading indicator around until the lead image has completed loading, even though it might be way down the bottom of SearchVue and the relationship may not be clear?

It was there for both cases but since we don't have Interwiki link right now it was intended to be there until everything was fully loaded including images. Because we need some indication otherwise it may not be clear that content is still loading even with placeholders. I can see that it may be confused with more content loading at the bottom so I am okay if we want to use the three dot explicitly for loading various sections. We can try a different approach to indicate loading of images something like this. What do you think?

Ooh, I like that! I think it's a very clean solution.

• loading data that we don't yet know whether it exists at all: animated dots
• loading data for which we already (most likely) know the structure: animated placeholder/skeleton
• when ready: actual content

cc @SimoneThisDot

I am going to implement this solution now. I think it is a good change and it would really improve UX.

@Sneha I have implemented the suggested animation on the current background colours, but I feel like the animation can barely be seen as the background is too light. We may have to change the colour to be a little darker for it to be more visible (or leave it as it is so that the animation is not too visible).

To illustrate @SimoneThisDot's point about colors:

• this is the proposed animation with our current background color: https://codepen.io/matthiasmullie/pen/BaVyGBO
• and this is the same with base80 instead of (current) base90 background color: https://codepen.io/matthiasmullie/pen/eYKmQYm

Or if we want to stick with the same background color, we can make the white animation a bit more pronounced as well: https://codepen.io/matthiasmullie/pen/dyKPQyR (still quite subtle though - very little contrast between our gray & the white)

Btw - I assume we would want this same colors & animation on those grey lines (for description & snippet) as well?

ah yes the current background is too subtle. However, what I have in the mocks for commons skeleton looks slightly darker. Can you make sure it is the same background we are using as I can't figure out if I am using base 80 or 90 since the names of colour styles in design system have changed. I noticed that the the box colour for lead image in my mocks is slightly lighter than the one I am using elsewhere (snippets and commons skeleton). If the commons skeleton colour in the mocks works for the animation we can make it the same everywhere even for lead image. And yes same colour and animation would be nice for grey lines too but it seems like they load pretty fast.

The mocks use #EAECF0 for Commons placeholders, which is base80. So sounds like we should adjust it to that darker color, which immediately makes the animation more obvious!

cool then I will also make it consistently base 80 in my mocks.

I will modify this right now!

With that color is more visible indeed!

Change 849048 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Loading content in Search Previews

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

For @Sneha review - see the animated gifs below. Any adjustments?

• Loading a skeleton for when the article has image

• Loading a skeleton for when article has no image.

The loading dots are a bit bigger than what's defined in specs. Also it is supposed to be blue.
For the animation on the box I wonder why it looks pixelated. Are you testing on a lower resolution? @Etonkovidova

After debugging https://phabricator.wikimedia.org/T322886 I realized that there is no wireframe for SearchVue widget combined with the footer and pagination. Currently, I've implemented (in progress) rendering quick view that aligns with the top of the search list element, see this shot:

But when it comes to represent widget at the bottom, it looks like that:

cc: @Sneha , @SimoneThisDot

Hi @vadim-kovalenko Your proposal is how I expected the quick view positions to work. It may not have been very clear but the AC below is meant to address the issue you pointed out. So if the user clicks on the results that are lower on the screen then quick view should be positioned high enough for users to see most of its content (at the same time not too high enough that it goes off the screen at top) If the quick view is too tall (longer than the available hieght on the screen) then it is okay for some of its part to go over footer. The goal is to have most of the content of the quick view visible above the fold.

• Position the panel as high as possible on the screen with arrow still pointing to the lower half of the panel.

Thanks, @Sneha, that's exactly what I meant.

@Sneha, I've noticed another corner case with SearchVue alignment. Steps to reproduce:

1. We have a long list of search results, and one of them is present in the URL
2. User scrolls to the very top.
3. User refreshes the page.

UX bug: user doesn't not able to see that particular quick view till he scrolls to the middle or bottom of the page.

Hi @vadim-kovalenko I am not sure if I understand this bug correctly. I would assume that if the user refreshes the page we would reset the page and any previously opened quick view would be closed.

@Sneha If the user refreshes the page but there is quickView in the URL, quick view should be opened. And If this quick view was somewhere at the bottom of the page, this might be misleading.

@vadim-kovalenko okay got it. I did not realize opening a quick view was actually "creating a new link" in the URL. I think if the user refreshes the page I would reset the page to when users first performed the search without any quick view opened (i.e. close all quick views). Is that possible? Since quick view is not a "page" to the user but just a UI element on the screen, having it disappear and starting from top of the page seems normal behaviour to me.

Hi @Etonkovidova I checked this implementation and everything looks great except the size of the three dot loading indicator. It is quite large. Also the design system team suggested we use the blue as shown in Figma for this indicator.

@SimoneThisDot Looks like this ticket is assigned to you. Are you using the loading indicator from OOUI library or is it custom? If custom then we can match it to what I have in Figma.

Actually I realized its pure CSS. Here is the size difference between what it is and what we should have. See the last one here it is closest to Figma in terms of size and colour. It was shared by DS designer.

Change 866362 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[mediawiki/extensions/SearchVue@master] Loading content in Search Previews

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

Colour and size changes have been implemented and are currently in review!

Change 866362 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Loading content in Search Previews

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

For Design review - @Sneha: there is some issues with a search preview placement which is out of scope for this ticket.

I checked the following - please review if everything looks as expected.

(1)
✅ - the content does not jump around while loading i.e. the user experience of loading content is smooth.

✅ - there is a visual indication that content is still loading

(2)

• A skeleton for when the article has image

mockup	betalabs (animated gif) throttling- slow 3G

• A skeleton for when article has no image.

mockup	betalabs (animated gif) throttling- slow 3G

(3) (for additional review by @Sneha) The discussion of the quickview behavior upon refreshing the page (https://phabricator.wikimedia.org/T318951#8418044 and https://phabricator.wikimedia.org/T318951#8418044). The current behavior:

• a user opens QuickView anywhere on the Search page
• a user scrolls the page, so the QuickView is out of viewport
• a user refreshes the page - two things happened when the page loads
• the Quickview is still open
• a user is taken to the position where the reload was initiated.

Probably, the behavior would look more logical as per this comment: https://phabricator.wikimedia.org/T318951#8418044:

I think if the user refreshes the page I would reset the page to when users first performed the search without any quick view opened (i.e. close all quick views). Is that possible? Since quick view is not a "page" to the user but just a UI element on the screen, having it disappear and starting from top of the page seems normal behaviour to me.

If any changes are going to be implemented, it'd make sense to create a new ticket.

@Etonkovidova Comments in #1 and #2 looks good to me except this video your shared. Looks like a glitch/bug as the horizontal lines (placeholder for text) should not animate like that it's just supposed to there.

For #3 I think its part of another ticket and the solution was mentioned in this comment.

In T318951#8455728, @Sneha wrote:

@Etonkovidova Comments in #1 and #2 looks good to me except this video your shared. Looks like a glitch/bug as the horizontal lines (placeholder for text) should not animate like that it's just supposed to there.

For #3 I think its part of another ticket and the solution was mentioned in this comment.

@Sneha does this need to be moved back to Doing for a fix then?

@Etonkovidova I just checked on beta and refreshing the page maintains the user scroll position when the preview open (which is different from what I had suggested). However this solution also works well and I think we can leave it as is and mark as done if there are no further bugs with it.

The only thing I would improve is if the preview was not opened perhaps refreshing could take users back to top. But since "maintaining the scroll position on refresh" is how it currently works in production we can leave as is.

In T318951#8456985, @Sneha wrote:

@Etonkovidova I just checked on beta and refreshing the page maintains the user scroll position when the preview open (which is different from what I had suggested). However this solution also works well and I think we can leave it as is and mark as done if there are no further bugs with it.

The only thing I would improve is if the preview was not opened perhaps refreshing could take users back to top. But since "maintaining the scroll position on refresh" is how it currently works in production we can leave as is.

Thanks, @Sneha! Moving to Verify on Production.