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

[mediawiki/extensions/SearchVue@master] Quick View: Enable users to open and close quick views on special:search

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

Change 817303 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Quick View: Enable users to open and close quick views on special:search

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

Blocked until the QuickView extension is deployed to beta cluster and this can be tested.

@Sneha The prototype mentioned in the description (under "scrolling") no longer seems to work; do you have another copy of that?

Ah I think I broke the link when I moved prototype to a different file. Here's the latest. I will update in the description too. Note that it does not scroll the page to the top like we have in media search and in your beta version due to limitation of prototype.

In T306885#8341897, @Sneha wrote:

Ah I think I broke the link when I moved prototype to a different file. Here's the latest. I will update in the description too. Note that it does not scroll the page to the top like we have in media search and in your beta version due to limitation of prototype.

That "scroll to the top" (see T318748) is exactly why I wanted to check out the prototype :D
While playing around with it on beta, with actual results, I've found it a bit annoying when clicking on a result far down the page & have SearchVue scroll me back to the top; it makes me lose track of where I was in the search results. Is it intended to work like this?

Ah got it. I think the initial idea was to scroll to top for the first quick view not for all because otherwise it can be too disorienting if it kept changing it position all the time.

Also only when the UI above search results is visible. If it is already above the fold we don't need to scroll to the top. The original intention was to just allow more space by hiding some of the UI on the top.

Checked in betalabs. The comments below are for @SimoneThisDot review.

(1) (a very minor issue) - in old Vector articles' snippets are displayed on three lines instead of two, It creates an empty space between a snippet and a QuickView.

(2) The following two requirements could be in conflict with each other.

• The position of the quick view should respect the position of the snippet i.e. the quick view could open near the bottom of the page if the snippet is at the bottom of the page. We need to make sure that the arrow is pointing to its quick view.
• Position the quick view on the page in a way that the maximum of its content is visible.

Presently, if a user clicks a snippet at the bottom of the page, the page will scroll up to accommodate the length of a snippet.
(click on the animated gif)

The screenshots show the different size of QuickView display:

(3)

Turn the opacity of the sister project contents down as shown in Figma, when the quick view is open. This is because some quick view may be smaller in size and the overlapping content could be distracting.

Presently the sister projects are displayed above the QuickView

Hi Elena, I am super excited to see that you are now able to test the Search Preview! :)

So let's answer your questions:

(1) (a very minor issue) - in old Vector articles' snippets are displayed on three lines instead of two, It creates an empty space between a snippet and a QuickView.

This is not actually due to this ticket (as this ticket did not modify the search preview at all, it just added the arrow dynamically). A full revision of the layout on old vector will be completed on this ticket: https://phabricator.wikimedia.org/T312269

(2) The following two requirements could be in conflict with each other.
This requirement have actually changed and the placement of the search preview is going to be handled in this ticket https://phabricator.wikimedia.org/T318951

Presently the sister projects are displayed above the QuickView
This one was completely missed! I will work on it now!

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

[mediawiki/extensions/SearchVue@master] Quick View: Enable users to open and close quick views on special:search page

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

Change 849466 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Quick View: Enable users to open and close quick views on special:search page

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

The below AC which was marked as completed seems to be not working correctly on the beta link. The arrows show up on hover but don't stay on the screen if the mouse is moved away from snippet. The correct behaviour is that once the quick view is opened the arrow needs to stay on the screen until its closed or another quick view is opened.

• Show arrow pointing to the quick view, establishing the connection between the result selected and quick view.

Also I noticed the preview used to scroll independently of the search results which was the correct behaviour. But now the entire page is scrolling at once.

@SimoneThisDot would you prefer to move this ticket back to Doing to address Sneha's comments, or create a new ticket?

The position of the quick view is not relative to the results clicked. It is right now aligning to the very top. Is this something we are going to fix in the loading quick view ticket or this one?

In T306885#8354140, @Sneha wrote:

The below AC which was marked as completed seems to be not working correctly on the beta link. The arrows show up on hover but don't stay on the screen if the mouse is moved away from snippet. The correct behaviour is that once the quick view is opened the arrow needs to stay on the screen until its closed or another quick view is opened.

• Show arrow pointing to the quick view, establishing the connection between the result selected and quick view.

Thanks, @Sneha! I didn't quite realize that the above requirement includes the AC that the arrow should stay.

I didn't mark the following requirement as complete though :)

We need to make sure that the arrow is pointing to its quick view.

I looked at T318951: [L] Loading content in Search Previews - the task has the AC that captures the behavior of the arrow:

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

In T306885#8354143, @Sneha wrote:

Also I noticed the preview used to scroll independently of the search results which was the correct behaviour. But now the entire page is scrolling at once.

There were several fixes that greatly improved the scrolling and displaying the QuickView, e.g. I moved T318748 for Design QA. Does that task address the issue you mentioned? There is still T322886: Search improvements - not closed QuickView disregards article snippet position though.

To summarize:

• I re-checked the scrolling behavior and the QuickView display (including the issues reported in my comment) - they are done or have been filed as separate tasks.
• I marked as complete the following ACs:

Position the quick view on the page in a way that the maximum of its content is visible.
Turn the opacity of the sister project contents down as shown in Figma, when the quick view is open. This is because some quick view may be smaller in size and the overlapping content could be distracting.

• These two ACs are still open:

The position of the quick view should respect the position of the snippet i.e. the quick view could open near the bottom of the page if the snippet is > at the bottom of the page. We need to make sure that the arrow is pointing to its quick view. (see T318951)

and

Scrolling

The scrolling behaviour on the page when the quick view is open is somewhat captured in this prototype.

I think that this task can be kept in QA column as a reference, so the open ACs can be checked after the specific phab tickets addressing outstanding issues will be done.

Hi Elena, I think there are some issues with the position of quick view. Many times it's off the screen and is not relative to the snippet. I think perhaps I need to discuss this with @SimoneThisDot to understand what is going on.

Hello was playing around with the beta version and just wanted to point out that it seems that the scrolling of search preview is different than specified here. In the prototype you can see that users will be able to scroll the preview up and down independent to the search results. Right now the entire page scrolls up together. If anyone is still working on this happy to discuss this more in detail over a call.

In T306885#8422347, @Sneha wrote:

Hello was playing around with the beta version and just wanted to point out that it seems that the scrolling of search preview is different than specified here. In the prototype you can see that users will be able to scroll the preview up and down independent to the search results. Right now the entire page scrolls up together. If anyone is still working on this happy to discuss this more in detail over a call.

Thx, @Sneha! After our meeting I re-checked and reviewed the specs on this task and two issues related to the scrolling/positioning.
Summary

• the following specs are still not marked as complete

(1)

The position of the quick view should respect the position of the snippet i.e. the quick view could open near the bottom of the page if the snippet is
at the bottom of the page.

• T322886: Search improvements - not closed QuickView disregards article snippet position - seems to be fixed but there is still an open patch though - anything else needs to be done?

(2)

Scrolling

There are two issues:

In T306885#8422347, @Sneha wrote:

Hello was playing around with the beta version and just wanted to point out that it seems that the scrolling of search preview is different than specified here. In the prototype you can see that users will be able to scroll the preview up and down independent to the search results. Right now the entire page scrolls up together.

and

• T323844: [M] The Search Preview appears above the fold in some cases

@SimoneThisDot @vadim-kovalenko I have separated the scrolling behaviour from this ticket and created a new one here T324278 based on our discussion.