@Sneha Do you think we can move forward with this, as it's currently described? (the description is just a copy of the discussion in T320577: [M] Update the special:search layout for Vector 2022 to use full screen width)

This would mean we will allow no side-by-side results + interwiki (and consequently, also no SearchVue) on screens with a resolution lower than 1000px for now.
I have filed T321377: [S] Figure out how to show SearchVue on small screens in non-mobile skins to address that, but I think that part can be moved to a later milestone.

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

[mediawiki/core@master] Make search results page widths more consistent

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

okay perfect. Thanks for creating a new ticket. This looks good.

Although I do think eventually we will have to align with proper grids from design system when we introduce grid system on this page. This may be a solution for now.

@matthiasmullie Are we going to cover this bug T322074 as part of this ticket?

In T312269#8376374, @Sneha wrote:

@matthiasmullie Are we going to cover this bug T322074 as part of this ticket?

Let's keep that in the other ticket since both things are in completely different areas of code!

Hei @Sneha, While reviewing this ticket (testing it locally), I noticed something that requires your input.

The current implementation, define the search result content to take 8/12 of the space. This is great when the interwiki result is there, but when the results are not there, this produces a large white space on the right-hand side:

While discussing with Matthias, he argued (correctly) that the white space is needed to ensure the SearchView does not cover existing results.

There are 3 possible solutions I see from here:

• We leave it as it is, it does not matter the white space
• Should we remove the white space when there is no interwiki (and allow the content to take 12/12 of space). When the searchView opens, it will go on TOP of the search result
• Should we remove the white space when there is no interwiki (and allow the content to take 12/12 of space). When the searchView opens, the search result width shrinks to create the white space

@SimoneThisDot The screenshot above has the menu open. I am assuming when the menu closes the width will be larger but still follow 8/12 rules of the available width.

For the empty space options, I think we should leave it as it is (i.e. white space on the side when interwiki links are not available) so there is some consistency with the way results are shown. Also I think as a general ux practice we should never let the quick view go over the search results. Also because the item in the search result has an arrow pointing to the quick view indicating its connection.

Ok great in that case the Patch is ready to be merged! (i do not have +2 but will give my vote and comment)

Change 843485 merged by jenkins-bot:

[mediawiki/core@master] Make search results page widths more consistent

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

Re: this discussion and this ticket.

I did some explorations on the cut off size and I think instead of 1000px we should go with 768px to cover more sizes on tablet. According to this list there are very few # of tablet devices below that size. I did some explorations for 768px and it seems doable if not the best.

{F35816445}

We still need to figure out what we do for devices smaller than 768px that do not have mobile skin. Which will be covered in T321377.

Are we able to update the AC as part of this ticket? Or should we create a new ticket? @matthiasmullie @SimoneThisDot

Let's create a new ticket; the patch has already been merged and is big enough to move forward with QA right away!

okay sounds good perhaps we can cover all the details in T321377 ticket instead of creating new ticket.

@SimoneThisDot I had another idea for when there are no interwiki links. we can have the first quick view open by default. I know this ticket is already done so something I can include in a new ticket. Just wanted to hear thoughts on the idea if anyone has any.

Ignore my idea above because that may not work as I explore this issue and other tablet sizing issues more. I will add more details in a separate ticket.