Page MenuHomePhabricator

[M] Enable new hover states on special:search page results
Closed, ResolvedPublic

Description

This ticket is to provide proper visual affordances and hover interactions for various elements in the search results.

Current hover states that should remain as it is. (Desktop)
Currently we have hover states on blue links which when interacted with also opens a preview of an article along side underlining the text. This interaction will remain as it is and we should make sure it stays intact in the new UI.

New hover state for quick view (Desktop)
To make users aware of quick view while browsing results, we are introducing a hover state on snippets. When the mouse is over the snippets an arrow appears on the right side of the snippet pointing towards right indicating that it is an interactive element on the screen that opens a quick view on the right.

Other Acceptance Criteria
Make sure the hover state doesn't show for users who don't have javascript or for users on mobile.

User testing note: This visual affordance will be validate in user testing and tweaks could be may be made if we find that this is not discoverable or usable.

User testing update and new acceptance criteria (Added Sep 1)
It was observed in the test that some users while hovering over the snippet moved their cursor over to the arrow to click on it. However moving the arrow outside the snippet area would make the arrow disappear.
To fix this issue:

  • Expand the hover and click zone to include the area in which the arrow appears.
    • If possible, it would be nice to have the zone expand upon hover and leave the original hover zone as snippet only.

New Acceptance Criteria (Added Sep 29)
Refer to the comments to see the discussion on expanding click zones.

  • Expland the hover and click zone to include the metadata line as well as shown in the image below.

Special_Search.png (800×1 px, 117 KB)

Link to prototype
Link to arrows position and style in figma

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Sneha renamed this task from Hover states on special:search results to Enable new hover states on special:search page results.Jun 10 2022, 6:10 PM
Sneha updated the task description. (Show Details)
CBogen renamed this task from Enable new hover states on special:search page results to [M] Enable new hover states on special:search page results.Aug 24 2022, 4:53 PM
CBogen updated the task description. (Show Details)

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

[mediawiki/extensions/SearchVue@master] Enable new hover states on special:search page results

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

Sneha updated the task description. (Show Details)
Sneha added a subscriber: CBogen.

@CBogen @SimoneThisDot Added the new acceptance criteria in the description under the header "User testing update and new acceptance criteria."

Both AC have been completed in the last patch update

Change 826555 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Enable new hover states on special:search page results

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

Simone's patch is merged & implements what is described in the description, however I have 2 questions/remarks.

#1. The description states:

When the mouse is over the snippets an arrow appears

This is exactly what has now been implemented: users can click the snippet text to show quickview, and hovering the snippet text will show the arrow.
However, I would like to propose that we apply this on the entire result instead of just the snippet text.
Reasons:

  • it's quite common to expect an item from a list (the entire search result) to be interactive; not so for a simple bit of text with no explicit markup, though
  • the snippet text can be a rather small target; while it's often 2 lines, it could also be as small as a few words. And there's a lot of other "search result information" surrounding it (e.g. title, category/section/redirect, metadata)

It also more closely matches the prototype, IMO: while the target in there is in fact only the snippet text, it makes up for the majority of the search result because it assumes long snippets & no category/section/redirect or metadata.

Of course, it shouldn't absorb clicks from the title; any clicks on the title would obviously still have to go directly to the article (which I assume was the reason that it's not part of the quickview-click/arrow-hover target?)

#2. Missing from the description (so not yet implemented) but implied in this mock: I assume we want the cursor to change to a hand pointer when the user hovers the target?

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

@matthiasmullie Can you visually show what you mean by full result being clickable? Since we need to keep the title as a separate link that goes straight to the article, how would the full result click work? Would it include thumbnail too? We can discuss more this new proposal and see if we want to create a new ticket for it.

In the prototype I had the following area (highlighted below) as a hit zone.

Special_Search.png (800×1 px, 116 KB)

Pink = current implementation, where only the snippet is the click/touch target for opening quickview (green = click goes to whatever the link is for)
Blue = proposed alternative, where the entire result is the click/touch target for opening quickview (links, green, when clicked still go to whatever the link is for) - basically: clicking any part of the result will open quickview, unless it's another link.

Special_Search.png (800×1 px, 123 KB)

Note: I've shrunk one of the snippets to simulate little content; most articles will have sufficient content to fill more than 1 line, but that's not always the case (especially once we'll consider expanding to other wikis)

Personally, I'd probably also include thumbnails, but they already have existing interaction anyway (MultiMediaViewer takes over)

If we have time, is it possible to quickly try it out and compare? I am curious to see how overlapping click zones feel while using.

We can also try to simply expand the click zones to also include the meta data and leave the title area exclusive to links.

Sneha added a subscriber: Simone19751975.

@Simone19751975 Added the new AC to description

@Simone19751975 Added the new AC to description

I think you meant to tag @SimoneThisDot :)

oops yes thanks for correcting

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

[mediawiki/extensions/SearchVue@master] Increase hover space on special:search

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

Change 838081 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Increase hover space on special:search

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

I'm assuming this is blocked on the SearchVue deploy for QA; please correct me if it's blocked on something else.

Correct. All is done and in place, just awaiting deployment

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

[mediawiki/extensions/SearchVue@master] Fix arrow & hover

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

Change 844486 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Fix arrow & hover

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

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

[mediawiki/extensions/SearchVue@master] Add cursor: pointer; when hovering target to enable quickview

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

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

[mediawiki/core@master] Switch search results padding-bottom to margin-bottom

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

Change 848165 merged by jenkins-bot:

[mediawiki/extensions/SearchVue@master] Add cursor: pointer; when hovering target to enable quickview

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

Change 848185 merged by jenkins-bot:

[mediawiki/core@master] Switch search results padding-bottom to margin-bottom

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

Etonkovidova subscribed.

Checked in betalabs- works as expected, per the mockup in https://phabricator.wikimedia.org/T310281#8244590 ( (blue colored area will provide an arrow on hover)

Special_Search.png (800×1 px, 123 KB)

Checked after deployment (wmf.17) to ruwiki, ptwiki, and idwiki - works as expected.

I'm moving the task for @Sneha quick review whether some additional adjustments for hover up area is needed. Sometime it feels not so inturitive to bring the arrows up, especially on ptwiki (see the gif below taken from T326383: [wmf.17-minor] Special:Search preview overlapping elements on a page):

hover_state.gif (734×1 px, 113 KB)

@Etonkovidova good catch.. and yes as discussed I have filed a bug for the issue you mentioned. T326580