Page MenuHomePhabricator

Improve support for commenting in lengthy discussions on mobile
Closed, ResolvedPublic

Description

Issue "1a" in T254208 names how it can be difficult to use the Reply tool to respond to a comment that has many existing replies. In these cases, it's likely you are not able to simultaneously see: i) the comment you are wanting to respond to and ii) the text input area where you are writing said response.

This task involves revising how and where the Reply Tool opens on mobile to address the issue described above.

Thank you to @Samwalton9 for bringing my attention back this issue.

Stories

When I want to respond to a comment to which [many] other people have already responded, I want to be able to view the comment I am responding to while simultaneously being able to draft a comment in response to it, so that I can ensure what I am saying sufficiently responds to what inspired me to say something in the first place without needing to A) scroll back and forth between what I’m writing and the comment I’m responding to and B) hold the comment I’m responding to in my memory.

Approaches

TBD: Editing Engineering to implement an initial approach and refine with Product's input.

Mockups

While the Editing Team is without a designer, we will be moving forward with implementation before mockups are prepared.

Requirements

@ppelberg will document requirements once we define and converge on an initial approach to the user experience.

Done

  • 1. Editing Engineering implements an initial approach
  • 2. Product provides feedback on initial approach
  • 3. Requirements are finalized
  • 4. Editing Engineering implements adjustments we converged on "2."

Event Timeline

An option proposed on the parent task for desktop as was to make the reply input "sticky": https://patchdemo.wmflabs.org/wikis/cc54aa1d20/wiki/Talk:DiscussionTools

This could work on mobile too. We would need to restrict the height of the reply tool so that some of the document is always visible.

When the keyboard is open, it might not be possible to see keyboard + replyinput + talk page, especially on smaller devices.

Change 811743 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Show a "Return to reply" button when widget is scrolled off the screen

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

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/7d8559199e/w/

I think the above works well on desktop an mobile.

The feature does not work so well on iOS when the virtual keyboard is open, as the browser starts to lie about what is visible on the page, however this is going to be an issue with any feature that depends on knowing how visible the reply widget is when scrolling, so we may just have to accept that as a limitation.

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/7d8559199e/w/

@Esanders: assuming the below accurately describes the way what you implemented works, then I support us deploying this on both mobile and desktop.

I think this is a valuable, low risk improvement...nicely done.

Two tweaks:

  • On desktop, can we make it so that upon clicking the ⌄ Return to reply button/hint, people are taken to the Reply Tool they have open and their cursor is focused within the Reply Tool's text input? Currently, the Reply Tool appears to be in a "focused" / "activated" state (text input area is surrounded by a blue border and the tools within the toolbar are rendered in black and bolded type, but the cursor is not flashing within the tool's text input.
  • Per what you shared in T310967#8061431, on iOS, can we make it so that when the virtual keyboard is open we explicitly disable the "Return to reply" feature?
    • Note: offline, @matmarex reminded us that on iOS, typing something will cause the text input to scroll back into focus.

Behavior

Desktop + Mobile
Case 1: Scrolling Up

  1. Open a Reply Tool (it doesn't matter whether you've entered any text into the text field or not)
  2. Scroll towards the top of the page, such that the Reply Tool you opened in "Step 1." is no longer in view
  3. Notice the ⌄ Return to reply button/hint appears at the bottom of the page
  4. Click/tap the ⌄ Return to reply button/hint appears at the bottom of the page
  5. ✅ Notice the page is scrolled such that the Reply Tool you opened in "Step 1." is both visible and focused

Case 2: Scrolling Down

  1. Open a Reply Tool (it doesn't matter whether you've entered any text into the text field or not)
  2. Scroll towards the bottom of the page, such that the Reply Tool you opened in "Step 1." is no longer in view
  3. Notice the ˄ Return to reply button/hint appears at the top of the page
  4. Click/tap the ˄ Return to reply button/hint appears at the top of the page
  5. ✅ Notice the page is scrolled such that the Reply Tool you opened in "Step 1." is both visible and focused

I can't reproduce the issue you describe on desktop, I've tested in Chrome+FF+Safari and the clicking the button places a flashing cursor.

Notice the page is scrolled such that the Reply Tool you opened in "Step 1." is both visible and focused

We can only properly place the cursor on desktop as on mobile we arent't allowed to programmatically trigger the virtual keyboard to open - so the expected behaviour on mobile is that the reply tool is visually focused (blue outline), but no real cursor is placed until you tap on it.

Change 811743 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Show a "Return to reply/new topic" button when widget is scrolled off the screen

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

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/7d8559199e/w/