"Search MediaSearch for images related to either the title of the article or the QID of the article"

We may not want to search based on article title: the results in QuickView will be expected to be directly associated with the search result, and some of these will almost certainly be wrong when there's some similarity between terms (which is likely when browsing search results) but not enough content for all of them.
E.g. almost none of the MediaSearch results for "Seal Brown" are a good match for the article.
Using only the Q ids will have a significant impact on the amount of available results (especially for less popular results/articles), but is probably safer than showing wrong results (which would also occur more often for less popular topics)

In T310284#8181905, @matthiasmullie wrote:

Using only the Q ids will have a significant impact on the amount of available results (especially for less popular results/articles), but is probably safer than showing wrong results (which would also occur more often for less popular topics)

I think that's fine - the mocks show only 4 or so images anyway. @Sneha we might need to have a design solution for when there are fewer results than that?

Link to Slack discussion about how to display the image grid: https://wikimedia.slack.com/archives/C030Q2LL63T/p1662093403761549

TL;DR:

• 2 rows with fixed height
• thumbnail width flexes & img covers the full width
• a likely-large-enough amount of images (6+, I would imagine; check how many can fit in a portrait-dominated search) will be added to thumbs container
• container hides overflow after 2 rows height
• last image doesn't flex

Quick & dirty code example: https://codepen.io/matthiasmullie/pen/yLjLVap

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

[mediawiki/extensions/SearchVue@master] Quick View: Create commons widget and add to the quickview panel

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

Hi @Sneha I have raised a patch with all the required Ac but I have a comment to raise.

In one of the requirement (the one defined in Matthias message), it was asked to "last image doesn't flex".

This requirement has been completed in my patch, but it is quite resource intensive and I am not sure the benefits outweighs the costs. Do you have any strong preference in that requirement, or would you say that it could be removed making the ap loading simpler and less resource intensive?

Follow up from the above comment after a chat with Matthias.

We have discussed and agreed that for the first iteration we are going to actually remove the complex implementation, and just assign the flex rule (that prevents the image from stretching) on the last image and not the last image is shown.

This will produce the following scenarios:

• 6 images of mixed width: 2 images per row normally
• just 3 images returned: the image on the second row will NOT stretch
• 6 images where the 3 image is a large landscape image. This image on the second row WILL stretch, but due to the fact that it is large already, it will actually provide minimal impact.

My bad! I had suggested not stretching the last image, but failed to give enough background information.
I had suggested this to make sure that, if Commons simply doesn't provide enough images to fill the container, we may find ourselves with a very narrow image stretched to the full width of a container.

Simone initially made sure the last visible image never stretches & computing which end up being visible is indeed quite intensive.
I think this case is safe to ignore, though, since this will only happen when we have more than enough images but they're simply very wide already - too wide to fit another one next to it.
In that case, stretching it will not look nearly as bad as the case I had in mind, since it was very wide already - stretching this one (like with the rest of the thumbnails) is acceptable IMO.

Not sure what we finally landed on? The scenarios Simone outlined above, are they causing intensive computing?

Change 833370 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Quick View: Create commons widget and add to the quickview panel

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

@Seddon is this just blocked on the deploy to beta for QA, or is it blocked on something else?

@SimoneThisDot can you please address Sneha's comment above? thanks!

@Sneha We are requesting 6-7 images and are stuffing those in the grid; however many fit the 2 rows is what ends up being displayed, and those will stretch a little so it's a visually pleasing even experience.

There are 2 scenarios where we might find only 1 thumbnail on a row:

• we didn't find enough related images
• the images are too wide to fit more than one

If there simply aren't 6-7 images available, the last one could end up in a row all on its own.
Stretching that one (and it could very well be a rather narrow one) to the full width of the container would look terrible.
We chose to not stretch the very last image to make sure that doesn't happen.

We could also have enough images, but they are very wide, simply too wide to fit more than 1 on a row.
Figuring out which are visible is computationally quite expensive, though.
And having those too-wide-ones stretch isn't that much of a problem anyway:

• they already are extremely wide, they won't have to stretch too much,
• even if the last one doesn't stretch to full with, the first row may also have only 1 very wide image which still would stretch, and things would look inconsistent.

After discussing & testing this one, we figured it was more trouble than it was worth, and decided to address only the "not enough images" scenario.

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

[mediawiki/extensions/SearchVue@master] Fix unit test and bug with Commons implementation

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

Change 837622 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Fix unit test and bug with Commons implementation

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

Blocked on the deploy to beta for QA

@matthiasmullie thanks for summarizing. It makes sense to not stretch the last image which is what I expected to happen too. The inconsistency in the second scenario is also okay to have as it would be better than having a gap in the first row.

(1) Seven images displayed. Search enwiki betalabs - 'cat '

mockup	enwiki betalabs

Note: other wikis entries are supposed to be displayed on the QuickView like in the mockup?

(2) One image displayed. Search enwiki betalabs - search term "Aurelius and Natalia"

betalabs

Note: the image (https://commons.wikimedia.beta.wmflabs.org/w/index.php?search=Aurelius+and+Natalia&title=Special:MediaSearch&go=Go&type=image) never finishes loading - 503 Service unavailable. Clicking in the QuickView shows the image page without any problems.
another case: search term "music"

Testing notes for future testing:

• find articles that have QID in wbc_entity_usage table on enwiki betalabs.

I was checking the beta link and want to point out that "in Wikimedia commons"should not be a link as shown in the mock. It is supposed to be black fonts without linking anywhere. Right now it is confusing when both "view more" and "in wikimedia commons" are a link. Only "View more" is supposed to be a link. Can we reopen this so it can be fixed @Etonkovidova

Moving to Doing as per @Sneha's comment above. FYI @SimoneThisDot. This shouldn't be a Milestone 2 release blocker though.

Looks like we had a regression with "In Wikimedia Commons" - per @Etonkovidova's comment, the text used to be black & show the icon, but it looks like that is no longer the case and it looks just like the other links, which is indeed confusing. That should certainly be fixed.

That said - can we keep the link behind "In Wikimedia Commons" (which should indeed be black)?
After all, the only ones who would then notice that it's a link are going to be the ones who expect it to be one & click it (I am one of those expecting a link when seeing such branding)

Also note that the "view more" link is currently only shown when there are more images than those being shown. If we take away the link behind "In Wikimedia Commons", and we're not showing "view more" because there are no other images, we're left with no link. Semi-related discussion: T321001#8498313.

It is a good idea to at least turn it black for now and eventually remove the link. Right now we are not linking any of the sister project names. The focus is on linking the content. So I think it should be fine if there was no link when "view more" is not present. Users can still click on images and will be taken to commons. And same for other interwiki links the content will lead them to those projects.

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

[mediawiki/extensions/SearchVue@master] Fix link color

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

All changes made. Patch open

Change 877989 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Fix link color

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

Checked for the fix in betalabs:

Notes:

• filed T327020: Search preview - external links open in the same tab - links to commons are treated as internal links
• "View more" "In Wikimedia Commons" reads as one phrase but it's actually two different links which might be confusing
• "In Wikimedia Commons" link redirects to Main page on commons

Here's the link to mocks for commons widget. Note that the "In Wikimedia Commons" and all other projects names were not supposed to be a link.

In T310284#8528759, @Sneha wrote:

Here's the link to mocks for commons widget. Note that the "In Wikimedia Commons" and all other projects names were not supposed to be a link.

Filed it as a separate ticket - T327108: Search preview - Commons widget: "In Wikimedia Commons" should not be a link

In T310284#8498797, @Sneha wrote:

It is a good idea to at least turn it black for now and eventually remove the link. Right now we are not linking any of the sister project names. The focus is on linking the content. So I think it should be fine if there was no link when "view more" is not present. Users can still click on images and will be taken to commons. And same for other interwiki links the content will lead them to those projects.

Guys we decided in a few comments above to leave it as a link (but black) because most people expect this to be a link. I am happy to remove it, but in my last iteration, we decided not too..

In T310284#8530140, @SimoneThisDot wrote:

In T310284#8498797, @Sneha wrote:

It is a good idea to at least turn it black for now and eventually remove the link. Right now we are not linking any of the sister project names. The focus is on linking the content. So I think it should be fine if there was no link when "view more" is not present. Users can still click on images and will be taken to commons. And same for other interwiki links the content will lead them to those projects.

Guys we decided in a few comments above to leave it as a link (but black) because most people expect this to be a link. I am happy to remove it, but in my last iteration, we decided not too..

Thanks, I closed the new ticket based on this comment. @Etonkovidova can this ticket be closed otherwise?

most people expect this to be a link.

I am just curious who are we referring to here? Is it community feedback?

In T310284#8531957, @Sneha wrote:

most people expect this to be a link.

I am just curious who are we referring to here? Is it community feedback?

I assume that's referring to my earlier statement that

the only ones who would then notice that it's a link are going to be the ones who expect it to be one & click it