Page MenuHomePhabricator

Indicate when search results are from redirects (sometimes)
Open, In Progress, MediumPublic

Description

Description

In T296671 and T296225 we're changing the search results logic so that instead of showing the redirect page in the search results list, we show the actual page that the redirect points to. One potential downside of this is that people could get confused as to why the top search result doesn't match their search term. For example if someone types "Corn" they will now see "Maize":

Screen Shot 2022-03-03 at 6.46.45 PM.png (251×546 px, 43 KB)

Proposed solution

Sometimes we should indicate that the search result is a redirect, for example:

image.png (502×1 px, 155 KB)

However sometimes we should not indicate that the search result is a redirect because it would be redundant, for example:

image.png (332×1 px, 94 KB)

@TJones provided an initial recommendation for how we might decide when to indicate that the search result is a redirect and when not to:

Any ideas how to avoid showing this extra info in cases where it is redundant/unnecessary?

It depends on how fancy you want to get...

  • The simplest approach would be to not show the redirect if the redirect is a substring of the title (lowercasing everything before comparing)
  • More normalization than just lowercasing could help, too, such as removing spaces and/or punctuation (then QAnon, (the title) and Q Anon and Q-Anon (the redirects) would all be equivalent
    • IIRC, Javascript doesn't support Unicode regex shorthand like \p{L} or \p{P}, so you'd have to be careful with non-Latin scripts
    • You also would have to make sure neither the redirect nor the title normalize to the empty string (e.g., ; is a redirect to Semicolon).
  • Not 100% sure about the other way around, but if the redirect is longer than the title but the title is a substring of the redirect it would probably be okay to not show the redirect.
  • Cases like Einstein/Einstien/Enstein are doable, but may be too expensive or complex? (My heuristic would be, if the first letter is the same and the other difference is only a swap or one-character addition/deletion/swap, then hide the redirect. The fastest way (O(n) instead of regular edit distance, which is O(n²)) I can think of to do this is a minimum length of 4 or 5, and then remove matching prefix and suffix and if the remainders are both length < 2, or both length==2 and one the reverse of the other. Like I said, maybe too complex—and it may behave oddly with CJK titles.

So, my recommendation? Remove spaces and dashes from the title and the redirect and lowercase both. If neither is the empty string and one is a substring of the other, then don't show the redirect. It won't be perfect, but it will help a lot.

Event Timeline

The DST tentatively agreed that this task shouldn't be considered a blocker for the first release of Codex's TypeaheadSearch. We'll have to decide whether the improvement should be implemented by Codex (e.g. include a slot in menuItem) or handled by the application.

Removing WVUI with TypeaheadSearch now building on top of Codex and T310243.

@Jdlrobson @TJones — what is needed in order to make this change? Is there Search API stuff that needs to be changed, or is it mostly client/front-end work? cc @ovasileva @ldelench_wmf

@Jdlrobson @TJones — what is needed in order to make this change? Is there Search API stuff that needs to be changed, or is it mostly client/front-end work? cc @ovasileva @ldelench_wmf

Sorry, I don't know. I'm not familiar with the implementation plan. If whoever is doing the implementation needs help with the API or other implementation details, they can come talk to the Search team.

This is purely a Codex task at this point for the design systems team (with assistance from web team).

The API currently returns matchedTitle field to significant a redirect: https://en.wikipedia.org/w/rest.php/v1/search/title?q=Corn&limit=10 so I don't think any API changes are needed at this point. The TypeaheadSearch component would need an update to support an optional title annotation field at which point Vector would be able to pass in the content in the brackets.

The TypeaheadSearch component would need an update to support an optional title annotation field at which point Vector would be able to pass in the content in the brackets.

This sounds sensible to me. In the context of the WiKit Design System, we encountered a similar scenario where we needed to indicate extra information about particular suggestions in the Lookup component. We decided to make room for these labels in the component configuration:

Screenshot 2022-09-30 at 18.19.37.png (397×601 px, 49 KB)

From a system's perspective, we should decide whether the potential new slot should live in TypeaheadSearch or maybe (in order to cover further use cases) the MenuItem component.

This comment was removed by AnneT.

The component spec sheet for the menu item with supporting text has been created in T323987 and it's ready to be implemented in Codex.

Moving this to "following" since we are completing the Codex part (T323987) but likely won't implementing supporting text for redirects in Vector (this task).

@ovasileva @Jdlrobson this is ready for us to pick up, though temporarily blocked until on the release of the updated MenuItem component, which will happen next week (which means it’ll ride the train the following week).

ovasileva triaged this task as Medium priority.Nov 29 2022, 5:45 PM
ovasileva moved this task from Incoming to Planned future work on the Readers-Web-Backlog board.

MenuItem is now available AFAIK

Indeed, the new supportingText prop was included in the Codex release yesterday (0.4.0).