Page MenuHomePhabricator

Responsive layouts for special:search page
Open, Needs TriagePublic

Assigned To
Authored By
Sneha
Jul 6 2022, 6:08 PM
Referenced Files
Restricted File
Wed, Nov 23, 8:57 PM
F35774214: image.png
Mon, Nov 14, 11:33 AM
F35596451: newvector-2048.png
Oct 21 2022, 8:45 AM
File Not Attached
F35596441: newvector-1440.png
Oct 21 2022, 8:45 AM
File Not Attached
F35596439: newvector-1280.png
Oct 21 2022, 8:45 AM
File Not Attached
F35596437: newvector-1024.png
Oct 21 2022, 8:45 AM
File Not Attached
F35597116: newvector-800.png
Oct 21 2022, 8:45 AM
File Not Attached
F35596449: oldvector-2048.png
Oct 21 2022, 8:45 AM
File Not Attached

Description

Originally this story was to ensure the search results layout is organized as per the grid structures proposed by design system team and that it was responsive at various breakpoints.

It was clarified in our our “SDAW Search Experimentation Design weekly” meeting that we are not fundamentally changing the structure of the special:search page or building for vector 2022 as part of this phase of the search improvement project. The scope does not include fully fitting the page into the new system. Going halfway might be following the spirit of where we may go with this page structure in the future but fully changing the structure is out of scope.

The scope of this story is now updated to:

  • Ensuring the layout and spacing is responsive to different screen size at various breakpoints.

After a discussion related to possible breakpoints and layouts for various screens, here's the current thinking (across all skins):

  • don't show interwiki results on the side on screens smaller than desktop breakpoint (1000px); interwiki results will be displayed full width at the bottom
  • on screens wider than 1000px, we'll have 8/12 search results, 1/12 white space, 3/12 interwiki widget
    • note: at the very minimum (1000px), the search results will be smaller than 50em (more like ~45em)
    • note: if no interwiki widget, search results still won't grow wider than 8/12
  • on screens wider than 1440px, we'll have 7/12 search results, 1/12 white space, 3/12 interwiki widget, 1/12 whitespace

Here's what that looks like in common screen resolutions:

800px wide1024px wide1280px wide1440px wide2048 wide
old vector
oldvector-800.png (1×788 px, 311 KB)
oldvector-1024.png (1×2 px, 557 KB)
oldvector-1280.png (1×2 px, 601 KB)
oldvector-1440.png (1×2 px, 628 KB)
oldvector-2048.png (1×4 px, 652 KB)
new vector
newvector-800.png (1×787 px, 251 KB)
newvector-1024.png (1×2 px, 534 KB)
newvector-1280.png (1×2 px, 547 KB)
newvector-1440.png (1×2 px, 569 KB)
newvector-2048.png (1×4 px, 626 KB)

AC:

  • On screens smaller than 1000px, search results occupy the full width; interwiki results are displayed below search results
  • On screens wider than 1000px & smaller than 1440px, search results occupy 8/12 of available space, then 1/12 whitespace, then 3/12 interwiki widget
  • On screens wider than 1440px, search results occupy 7/12 of available space, then 1/12 whitespace, then 3/12 interwiki widget, then 1/12 whitespace
  • In the absence of interwiki widgets, search results width remains the same; whatever would be occupied by interwiki widgets remains blank

To confirm on:

Event Timeline

Sneha renamed this task from Organize search results in a proposed 12 column layout that is responsive at various breakpoints. to Responsive layouts for special:search page and quick view.Jul 26 2022, 8:13 PM
Sneha updated the task description. (Show Details)
Sneha updated the task description. (Show Details)
Sneha updated the task description. (Show Details)

@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: 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?

@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:

image.png (573×1 px, 114 KB)

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.