Page MenuHomePhabricator

Add a link: [Desktop] Enable link inspector to be collapsed
Closed, ResolvedPublic

Assigned To
Authored By
MMiller_WMF
Apr 26 2021, 6:00 PM
Referenced Files
F34765938: addlink_inspector_collapse_LTR.gif
Nov 24 2021, 11:36 PM
F34765941: addlink_inspector_collapse_RTL.gif
Nov 24 2021, 11:36 PM
F34725782: image.png
Nov 2 2021, 11:25 PM
F34725769: image.png
Nov 2 2021, 11:25 PM
F34725773: image.png
Nov 2 2021, 11:25 PM
F34725779: image.png
Nov 2 2021, 11:25 PM
F34725777: image.png
Nov 2 2021, 11:25 PM
F34487344: image.png
Jun 8 2021, 9:05 PM

Description

Problem

Because the link inspector is not dismissable by the user, it's possible that it can cover up article text that they would want to see when deciding on their suggestion. This edge case occurs on desktop in certain scenarios such as when only one suggestion is in the article (because the inspector can't go away, and the user can't even flip to a different suggestion to expose the obscured text for the other suggestion) and when the link suggestion is towards the very bottom of article content (where users can't scroll underneath the inspector).
Even when users can read article text by switching to another, there is certain level of lost context needed to switch to the another link inspector in order to read the text around the link suggestion being reviewed.

Example of the link inspector covering part of the sentence that contains the suggestion:

image.png (293×570 px, 33 KB)

Note: Since the issue on mobile is not about text being obscured but the annoyance of limited scrolling area, a separate task for mobile at T284609

User job story

When I am reviewing suggested link text and part of the text below the suggestion is covered by the link inspector card,
I want to be able to easily see the obscured text below the link inspector card,
So that I can get better context about what the link suggested relates to, and decide whether to accept or reject that link suggestion.

Proposed solutions

We will proceed with proposal B (enable closing the inspector on desktop) for consistency with mobile behaviour.

Proposal A. Enable moving the link inspector

Add an action that enables the user to drag the link inspector to a different location. If the user moves onto another link, the inspector returns to its normal position next to the link text.
Notes on design:

  • When the link inspector is moved, the callout arrow pointing to the text is hidden, to prevent the inspector from inadvertently pointing to unrelated text
  • For easier mobility, enable the entire header section of the inspector to be dragged, not only the move icon
1. Inspector with move icon
image.png (964×1 px, 518 KB)
2. Inspector is moved to another part of the screen
image.png (964×1 px, 582 KB)
  • Pros
    • User has control of where the inspector should go
    • Recovery by going to the next or previous suggestion
    • Maintains context with the link inspector connected to the link text
  • Cons
    • Additional control to the UI adds complexity and effort (esp. in comparison to proposal B)
    • Potential for inspector to be moved unwittingly to the wrong link suggestion
    • Potential for unexpected bugs and edge cases (moving inspector to an unrecoverable area, inspector not returning to the normal position, etc)
    • Potential a11y issues with drag
Proposal B. An explicit re-open button when the link inspector is hidden

Enable the user to hide the link inspector completely when tapping on a close button or inside the article content area.
Add a button that allows the inspector to be re-opened.
This is the same as proposal B on Mobile (T284609)

1. User taps on the close
image.png (964×1 px, 521 KB)
2. Link inspector is transitions to hidden the screen
image.png (964×1 px, 535 KB)
3. Link inspector can be brought up again by tapping on the Floating button with the robot on the bottom right (or if the user taps on a link suggestion tag in the article).
image.png (964×1 px, 508 KB)

A simplified version of this could be to not include the button, but toggle show/hide the inspector any time the user clicks on the article content area.

  • Pros
    • Users are familiar with clicking outside of pop-ups to dismiss them
    • Re-open button acts as an additional safeguard in case newcomers do not know how to re-open the inspector via clicking on the suggested link text again
    • Maintains context with the link inspector connected to the link text
    • Can work in concert with proposal to allow moving the inspector (the close icon would not be shown in this case)
  • Cons
    • Potential for conflicts with auto-advancing behaviour (e.g., user closes as the inspector as it auto advances)

Proposal A & B could potentially both be offered to enable different users the flexibility to either hide or move the inspector.

Desktop mocks on figma

Event Timeline

kostajh triaged this task as Medium priority.Apr 28 2021, 11:52 AM

Another suggestion: allow the user to drag the box to a different location. If the user moves onto another link, the inspector returns to its normal position next to the link text.

I think the minimum-effort solution would be a button to either flip the popup position or to hide the popup while the button is pressed down. Both are fairly simple to implement and do not risk the user somehow "locking out" themselves from the workflow and not figuring out how to get back.

We should think about this for mobile, too. On smaller devices, the link inspector can take up a big part of the viewable area, and it would be useful to have some way to minimize it so the reviewer can look at more of the article text.

Is there strong evidence against dismissible link inspector? To be clear - "dismissible" is clicking outside the link inspector (or to have a special close button) and be able to bring it back by clicking on a highlighted link again.

Reading the context around a suggested link (sometime reading a lot of text, potentially scrolling to different parts of article) is an essential part of Add link workflow. Holding down a button to keep it minimized is inconvenient, flipping or dragging the link inspector has disadvantages too - obscuring other portions of text or getting lost (disconnected) from the original highlighted item.
On mobile the scrollable portion of text is really small, allowing only about six lines of text to scroll.

RHo renamed this task from Add a link: link inspector can obscure text to Add a link: [Desktop] Undismissable link inspector can obscure text.Jun 8 2021, 9:05 PM
RHo updated the task description. (Show Details)

Updated task description with revised button styling for "?" help, and placement of "close" icon for proposal B.

RHo renamed this task from Add a link: [Desktop] Undismissable link inspector can obscure text to Add a link: [Desktop] Enable link inspector to be collapsed.Nov 17 2021, 12:33 PM
kostajh removed RHo as the assignee of this task.Nov 24 2021, 3:38 PM

Change 741742 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: allow the link inspector to be collapsed on desktop

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

With latest changes:
The link inspector can closed. Once closed, it can be re-opened by clicking on the robot icon or by clicking on the annotation view.

LTR:

addlink_inspector_collapse_LTR.gif (1×1 px, 1 MB)

RTL:

addlink_inspector_collapse_RTL.gif (1×1 px, 824 KB)

For instrumentation, the following actions were added (same as for T287404: Add a link: [Mobile]: Allow link inspector to be toggled shown/hidden):

  • close with recommendedlinktoolbar_dialog active_interface (when the inspector is closed)
  • reopen_dialog_click with machinesuggestions_mode active_interface (when the robot button is clicked)
  • impression with recommendedlinktoolbar_dialog active_interface (when the inspector re-appears)

Change 741742 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: allow the link inspector to be collapsed on desktop

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

Checked in wmf.13 - works as expected; the auto-advancing works as expected also (checked on LTR and RTL wikis).