Page MenuHomePhabricator

Add a link: [Mobile]: Allow link inspector to be toggled shown/hidden
Closed, ResolvedPublic

Assigned To
Authored By
RHo
Jul 26 2021, 6:48 PM
Referenced Files
F34597717: Help panel bottom OK.webm
Aug 16 2021, 5:01 PM
F34597451: iOS simulator issues.webm
Aug 16 2021, 8:44 AM
F34567312: addlink_collapseInspector.gif
Jul 27 2021, 10:04 PM
F34487326: image.png
Jul 26 2021, 6:48 PM
F34487322: image.png
Jul 26 2021, 6:48 PM
F34551179: image.png
Jul 26 2021, 6:48 PM
F34487330: image.png
Jul 26 2021, 6:48 PM

Description

This task breaks out one of the proposals on T284609 into a separate task to do first.

Problem

On mobile, the link inspector can take up a big part of the viewable area which makes it harder to read the text around a link suggestion. This is particularly an issue for smaller devices.

image.png (1×784 px, 247 KB)
(relatively limited scrollable article content area highlighted in magenta)

Proposed solution - Enable toggle showing the link inspector, with a persistent re-open action

Enable the user to hide the link inspector completely when tapping inside the article content area.
Add a button allows the inspector to be re-opened.

1. User taps in the article content area
image.png (640×360 px, 51 KB)
2. Link inspector is animates off the screen in dismissal
image.png (640×360 px, 65 KB)
3. Link inspector re-opened by tapping floating 'robot' button on the bottom right (or by tapping a link tag in the article).
image.png (640×360 px, 51 KB)

The re-open button is imagined here to be a floating action button on the bottom RHS of the screen under the inspector, but it may placed elsewhere (e.g., as a persistent button on the toolbar) or not at all it it's possible to toggle show/hide when tapping on the article content area.

  • Pros
    • Users are familiar with tapping outside of pop-ups to dismiss them
    • Floating action 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
    • No additional cognitive load as there is no UI addition to the inspector
    • Can work in concert with proposal for the responsive compact inspector layout for smaller devices
    • Ideally we should introduce to both Desktop and Mobile if this is selected as the solution.
  • Cons
    • Potential for conflicts with auto-advancing behaviour (e.g., user minimises as the inspector as it auto advances)
    • If introducing with the floating button which is a non-standard component, there may be unexpected issues with it appearing over/under device keyboards or UI content that need to be checked.
View mocks on Figma

Note: Per discussion on from T284609#7214781 the inspector will be toggled shown/hidden but an annotation will remain selected as per the current paradigm.

Event Timeline

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

[mediawiki/extensions/GrowthExperiments@master] [WIP] Add a link: show/hide link inspector on mobile

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

Hi @RHo @MMiller_WMF, a few clarifications:

  • What should the invisible label of the robot button be?
  • For instrumentation, do we need new events for these new actions? Are there any other things that need to be instrumented?
    • Closing the link inspector
    • Clicking on the robot button
    • Re-opening the link inspector

I wonder if it made sense to instead collapse the inspector to a single line (e.g. what was previously the top row of the inspector)? That seems achievable with much less code complexity.

I wonder if it made sense to instead collapse the inspector to a single line (e.g. what was previously the top row of the inspector)? That seems achievable with much less code complexity.

I agree with this, except that ideally I'd wanted to have the same solution for Desktop in the equivalent task T281185 rather than having two different styles of re-opening. @mewoph - would this be low effort to complete for Desktop as well?

Hi @RHo @MMiller_WMF, a few clarifications:

  • What should the invisible label of the robot button be?

How about "show link suggestion"?

  • For instrumentation, do we need new events for these new actions? Are there any other things that need to be instrumented?
    • Closing the link inspector
    • Clicking on the robot button
    • Re-opening the link inspector

This sgtm but @MMiller_WMF and perhaps @nettrom_WMF want to weigh in.

I agree with this, except that ideally I'd wanted to have the same solution for Desktop in the equivalent task T281185 rather than having two different styles of re-opening. @mewoph - would this be low effort to complete for Desktop as well?

The implementation I have so far for the button isn't mobile-specific so it should be fairly straightforward to apply this on desktop. The additional work on desktop would be to animate the link inspector in and out.

How about "show link suggestion"?

That sounds good, will add.

@mewoph -- thank you for thinking about instrumentation. Why did you list a separate event for clicking the robot button and for re-opening the link inspector? Are those not basically the same action/moment?

@MMiller_WMF The click leads to the link inspector being re-opened. From other places where a button leads to an action I see that we send separate actions even though the outcome can be implied. We're sending an impression when the link inspector is first shown, so with this new interaction, I was thinking there would be two events: 1) click on the robot button and 2) impression when the link inspector is shown again. We could get rid of 1) though.

@mewoph -- I see, yes you're right. Let's do both events.

  • For instrumentation, do we need new events for these new actions? Are there any other things that need to be instrumented?
    • Closing the link inspector
    • Clicking on the robot button
    • Re-opening the link inspector

I'm on the same page as you and Marshall that having both a robot button click and an impression for reopening the link inspector makes sense.

To make sure we're on the same page, what would these events look like? Would they all have active_interface set to recommendedlinktoolbar_dialog, with different values for action? Maybe hide_toolbar, show_toolbar, and impression for "closing", "clicking on the robot button", and the event for reopening? Other values would work fine too, I see we have a close action already, which doesn't seem to be used for that dialog anyway.

Hi @nettrom_WMF, would these additions make sense?

  • close with active_interface=recommendedlinktoolbar_dialog for when the user clicks outside the link inspector to close it
  • impression with active_interface=recommendedlinktoolbar_dialog for re-opening the link inspector
  • reopen_dialog_click for clicking on the robot button --- for this, would machinesuggestions_mode make more sense for active_interface since recommendedlinktoolbar_dialog isn't shown?

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

[schemas/event/secondary@master] Add a link: Update schema to support edit mode and link inspector toggles

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

Hi @nettrom_WMF, would these additions make sense?

  • close with active_interface=recommendedlinktoolbar_dialog for when the user clicks outside the link inspector to close it
  • impression with active_interface=recommendedlinktoolbar_dialog for re-opening the link inspector
  • reopen_dialog_click for clicking on the robot button --- for this, would machinesuggestions_mode make more sense for active_interface since recommendedlinktoolbar_dialog isn't shown?

The first two make total sense! I think the last one makes sense too, in that recommendedlinktoolbar_dialog refers to the interface element for judging the link itself ("Should this link to?" with buttons, etc…) Since, as you mention, that isn't shown when the button is clicked, it doesn't make sense to have that as active_interface (it's not active). Having machinesuggestions_mode as the active_interface then also makes sense to me.

Let me know if I missed something! If I didn't, this looks good to go!

Thanks for confirming @nettrom_WMF! I added reopen_dialog_click to the existing link_suggestion_interaction schema patch (https://gerrit.wikimedia.org/r/c/schemas/event/secondary/+/704402/) so we don't have to update the schema version twice.

Change 704402 merged by jenkins-bot:

[schemas/event/secondary@master] Add a link: Update schema to support edit mode and link inspector toggles; add client_ip

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

Change 708177 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: show/hide link inspector on mobile

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

Etonkovidova subscribed.

Checked on testwiki wmf.18 - both on iOS and Android (Samsung Galaxy S8) - all looks good. I'll do some additional testing when https://gerrit.wikimedia.org/r/708177 will be in production.

I think this task should get design review from @RHo. I'm reopening and putting in that column. Thank you!

Hi @Etonkovidova this looks good except I did notice a weird bug on the iOS simulator you might already be aware of for 'watching in prod' - the button does not seem to be working to re-open the inspector when it is on the last tag (or the page scrolled to the end):

Hi @RHo, this is because the button is close to the scrollbar so when the scroll is all the way to the bottom, the tap is then applied to the scrollbar. We have the same issue with the help panel button. The only solution would be to move the reopen dialog & help panel buttons further away from the right edge to accommodate the scrollbar tap area. If you'd like that change, please file a new task so that we can apply the same changes to both buttons.

Hi @RHo, this is because the button is close to the scrollbar so when the scroll is all the way to the bottom, the tap is then applied to the scrollbar. We have the same issue with the help panel button. The only solution would be to move the reopen dialog & help panel buttons further away from the right edge to accommodate the scrollbar tap area. If you'd like that change, please file a new task so that we can apply the same changes to both buttons.

Hi @mewoph - thanks for the explanation. However I can't seem to reproduce the same error on the help panel, since it self-corrects very easily to move the help button into the tap area and then opens the panel.

So I'm wondering if the same thing should happen for the inspector button on iOS in production? @Etonkovidova, would you be able to please review and determine if this is something that needs fixing as a separate task for both help and and inspector, or is it just iOS simulator weirdness?

Hi @RHo I think it's more rare on the help panel since the button is bigger. I was able to reproduce (on a real iOS device) when I tapped the right side of the help panel button.

Hi @RHo I think it's more rare on the help panel since the button is bigger. I was able to reproduce (on a real iOS device) when I tapped the right side of the help panel button.

OK gotcha, in that case I've file as T288985, though another pretty low prio bug imho.

Re-checked on wmf.18 and testwiki wmf.18 - no issues found; Resolved.