Topic on Talk:Talk pages project/Replying/Flow

I see that in the current prototype, when you have an editor open, all other reply buttons become grey and disabled. While I understand the technical reason for this (avoiding self edit conflict), perhaps an idea, is to have the grayed out links behave as a cancel as well. When you click them, have the UI go "To reply here, you have to cancel and reply you started elsewhere on this page but have not yet finished." Take me there-button, cancel other changes-button.

@TheDJ, thank you for taking a look at the prototype and great spot RE the disabled reply links.

Question: what did you think when you saw the disabled reply links? Was it something curious you noticed? Were they confusing? Something else?

In the meantime, some context about why reply links are disabled and what we have planned to improve the experience...

Why are reply links currently disabled when a text input is open?

The current version of the prototype does not have auto-save implemented.

This means, if a contributor was to:

1. Compose a reply in "Text input A"
2. Compose a reply in "Text input B"
3. Post the reply they drafted in "Text input B"
4. The comment they composed in "Text input A" would be discarded

In the time between now and when auto-saving is implemented, reply links are disabled when one text input is open so as to avoid a situation where a contributor's unposted draft(s) are unintentionally discarded.

What do we have planned to improve the experience?

In time, we plan to have a more robust auto-save implemented (see: See: T240257#5729386) which will enable contributors to compose multiple comments in parallel and eliminate the need for reply links being disabled.

cc @Iamjessklein

> what did you think when you saw the disabled reply links?

I figured: "i guess i can't use this right now. Maybe i have one open already... BUT WHERE on this huge page. scroll, scroll, scroll"

Thank you for clarifying this. Would you say the below [1] accurately describes what you encountered?

Context for my question: I'm trying to figure out whether what we're talking about in this thread is deserving of a separate ticket or whether the below adequately captures it.

---

1. "In long threads the reply textbox is a long way from the comment it is replying to (and the “Reply” button)...how should we handle/display the page when a lot of text means that there is a big gap between the original comment to which someone is attempting to reply, and the place where the reply will go? Where should the affordance for replying go? At the end of the original comment or the place where the reply will end up?" Source: T235923

Question: what did you think when you saw the disabled reply links?

I was surprised. It's unusual, eg. on reddit you can edit multiple answers, however I find that confusing (sometimes I forget how many replies I started...), so it's better to edit only one reply.

Actually I was most surprised, when I scrolled away and forgot where I clicked reply... had to scroll through the page to find it :D

An improvement that I suggest is to keep the editbox (it's parent div.oo-ui-inputWidget) on-screen, when it is scrolled out of the viewport with css position:fixed; bottom:0; (on bottom) or position:fixed; top:0; (on top), and add a button that scrolls the edited reply back to the center of the screen.

Thank you for adding your thoughts in here. Now to the approach you proposed:

...keep the edit box...on-screen, when it is scrolled out of the viewport...

This seems like it could be an effective way of making sure the text input is easily accessible regardless of where "you" are on the page.

Do you think this question is an adequate way of representing the issue?

"Do you think this question is an adequate way of representing the issue?"

I think this approach of keeping the edit box onscreen solves both problems, therefore it would be one task to implement it. However the two reports describe two different paths to get to a similar, confusing situation:

1. Replying to a comment that has too many replies (ca. 10 replies usually don't fit on the screen)
2. Replying to a comment and scrolling away at least one screen, while editing.

I think these use-cases should be investigated separately: the circumstances are somewhat different and it's possible the solution to each will differ in details. In case 1) I imagine clicking "reply" could automatically start moderate-paced scrolling to the end of the thread, where the new comment will be edited. In case 2) the user clicking a "return to edited comment" button would do the same.

Tl;dr: I think there is one solution to two related, but different problems. To properly address both, I think the two questions should be kept separate, while clarifying that a common solution will be implemented.

Thank you for clarifying! I think I've represented the scenario you are highlighting in Phabricator [1]. Although, please tell me if this is not the case.

---

1. https://phabricator.wikimedia.org/T235923#5761782

Exactly! Thank you.

We created a new ticket where we will think about this issue among others related to it: https://phabricator.wikimedia.org/T254208

On the one hand, it's probably good to make people focus. It can be helpful to finish the first thought before starting the second reply.

On the other hand, when I'm reading a l-o-n-g diff on an active page, I can open multiple sections in different tabs, so I can reply to all the things in turn, without needing to lose my place in the diff. I can't use the quick reply tool to do that, because it doesn't open in a tab.

This is a good use case to mention. It's documented in Phabricator here for our team to consider addressing in a future iteration: T235923#5761825.