Page MenuHomePhabricator

Revise position and behavior of Reply tool's text input
Open, Needs TriagePublic

Description

This is a task to capture the feedback reported about how and where the Reply tool's text input is presented and behaves.

The "Feedback" below could warrant a series discrete interventions that warrant their own tickets or a series of changes made together as part of this single ticket.

For now, we will use this task to accumulate feedback.

Feedback

IssueDescriptionTicketLinks
1a.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.@Demian: https://w.wiki/SYx.
1b.It can be difficult to use the Reply tool to respond to a comment while trying to view content elsewhere on the page. In these cases, it's likely you are not able to simultaneously see: i) the comment(s) you are wanting to view to inform the response you are writing and ii) the text input area where you are drafting said response.@Demian: https://w.wiki/SYx. @dialmove: https://w.wiki/Ti6. @Kaartic: https://w.wiki/USd
2a.After clicking a "Reply" link, it can be confusing/unexpected/unclear why you are unable to use the Reply tool to respond to a different comment on that same page.T257176@TheDJ: https://w.wiki/SYs; @Dvorapa: https://w.wiki/SYt
2b.If/when you discover the Reply tool being open elsewhere on the page is preventing you from responding elsewhere, people report being inclined to scroll the page to find where the Reply tool is open, which requires more effort than expected.T257176" " "
3.The Reply tool's text input can be too wide. I'm awaiting details on how large the person's browser window was when they experienced this and what negative impact(s) the width fo the Reply tool's text area had.T257280@Wladek92: https://w.wiki/SjF
4.When writing a long comment in the Reply tool's source mode, the "Reply" button can disappear from sight [because of the Preview].@dialmove: https://w.wiki/Ti6.
5.Expected the Reply tool's compose window to open right beneath the comment being replied to. TBD: whether the tool's behavior became clear to this person after they posted their comment.T259834@Gnom1: https://w.wiki/USH.

Event Timeline

ppelberg created this task.Jun 2 2020, 12:50 AM
ppelberg renamed this task from Revise position of Reply tool's text input to Revise behavior of Reply tool's text input.Jun 2 2020, 1:00 AM
ppelberg renamed this task from Revise behavior of Reply tool's text input to Revise position and behavior of Reply tool's text input.Jun 2 2020, 1:04 AM

Thank you @ppelberg for finding and collecting these feedback!

Jc86035 removed a subscriber: Jc86035.Jun 2 2020, 1:31 PM
ppelberg updated the task description. (Show Details)Jun 5 2020, 12:05 AM
ppelberg added a subscriber: Wladek92.
This comment was removed by ppelberg.
ppelberg updated the task description. (Show Details)EditedJun 11 2020, 12:00 AM
ppelberg added a subscriber: dialmove.

Task description update

  • Adding a link to the feedback @dialmove shared RE issue 1a. to the task description:

Second impression is "Where am I"? When clicking a post that has several earlier replies, the interface jumps down and the tool appears in the middle of a completely different conversation, in a new context with no visual indication of its relation to the initial comment we're replying to. | Source

  • Adding the issue @dialmove raised RE the "Reply" button disappearing from sight when composing a long comment in source

When writing a long comment in the Reply tool's source mode, the "Reply" button can disappear from sight [because of the Preview].

ppelberg updated the task description. (Show Details)Jun 11 2020, 12:27 AM
iamjessklein added a comment.EditedJun 15 2020, 2:34 PM

Re: 2a, we need to address the intermediate state for the "Reply" links elsewhere on the page that become "grayed out"/disabled when someone has the Reply tool open. see: T234403

Task description update
Adding the feedback @Gnom1 shared here to the task description as Issue #5:

I expected the edit window to open right under the comment that I selected to reply to, but it opened further down the page. So I asked myself whether my comment would end up further down instead.

ppelberg updated the task description. (Show Details)Jun 18 2020, 12:35 AM
ppelberg added a comment.EditedJun 18 2020, 12:45 AM

Copying over some relevant comments from another ticket...

Reddit in paticular has an intuitive comment editor, which resembles a lot what you're building here. They have an advantage though, their comments are shown in reverse order (recent commments first) so they don't have the problem that newer comments in long threads will be thrown all the way down to the end.

Maybe you could temporarily show the new post right below the comment you're replying to, just in the client side, yet still store it at the proper place of the thread, so that it will be moved when the page is refreshed.

Task description update
Adding a link to the feedback @Kaartic shared here to the task description as part of Issue #1b.

It would be nice to visually distinguish the editor so that it is easily identifiable amongst the content while scrolling through the page. When drafting a reply, I happened to scroll the page to see other content but lost track of the location of the editor. It took me some time to find this. Given that the positioning of the editor could vary unlike the editors in other places, I guess it would be nice to visually distinguish this in a better way so that it could easily be identified.

ppelberg updated the task description. (Show Details)Jun 18 2020, 2:13 AM

@Esanders what's the benefit of using position: fixed + JS compared to position: sticky + no JS?

Browser support?

Sorry, I've only linked it on the patch: https://caniuse.com/#feat=css-sticky
IE is out of the game. I wonder if that was the thinking behind the decision.
I think there are very few editors who use IE and talk pages, if any.

Well this is not a thing to debate, there must be some bulletproof statistics. Anyway from my experience, on Czech Wikipedia there is a surprisingly big number of IE users even today.

ppelberg updated the task description. (Show Details)Jul 6 2020, 4:36 AM

Task description update

  • ADDED the newly created ticket (T257176) for issues "2A" and "2B" in the task description's "Feedback" table.

When I click “cancel”, it jumps back to the comment I started replying to, because it focuses on the now-visible reply button. It was surprising for me, I would expect to stay where I am.

Well this is not a thing to debate, there must be some bulletproof statistics. Anyway from my experience, on Czech Wikipedia there is a surprisingly big number of IE users even today.

As long as IE11 is Grade A, not even any statistics can justify not supporting it. If we say we support it, we should support it as much as possible. Convenience is not a reason not to support it. However, something like this could work:

&-fix-top,
&-fix-bottom {
	position: fixed;
	position: sticky;
}

This makes it transition from one state to the other more seamless on modern browsers, while keeping support for IE. (Exactly this didn’t seem to work for me, but probably it can be made work.)

ppelberg updated the task description. (Show Details)Jul 6 2020, 11:33 PM

Task description update

  • Issue 3 will be considered as part of T252445; the "Feedback" table has been updated to reflect this.
ppelberg updated the task description. (Show Details)Jul 7 2020, 1:07 AM
ppelberg updated the task description. (Show Details)

Task description update
I've created a task to address – what I understand to be – a root of Issue #5:

5.Expected the Reply tool's compose window to open right beneath the comment being replied to. TBD: whether the tool's behavior became clear to this person after they posted their comment.T259834@Gnom1: https://w.wiki/USH.
Esanders added a comment.EditedAug 7 2020, 3:06 PM

Sticky is bounded by the parent element, so I don't think position sticky can be used here due to the widget being embedded deep in the DOM to take the correct position within the list.

One could hoist the widget out of the tree structure and then fake a placeholder and dynamically resize it, but that would result in more JS size computation and positioning, which would be slower overall.

Change 601350 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] WIP sticky replies

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

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/f7c62edd11ec30610e13c39c144ff94e/w/

I played a bit with the patchdemo (it’s very useful, many thanks for inventing and using it!). Some issues I found:

  • The reply interface is actually huge. Without any content, the source mode occupies about 40% of my ~700px viewport height when logged out (i.e. with anon warning), the visual mode even a bit more. If I scroll on the page, I probably want to something else than the reply interface. Maybe an option to collapse the interface into one line in floating mode?
  • If I write enough, the interface becomes higher than my viewport. If I start scrolling in this state, there’s no way to get back into non-floating mode, and no way at all to see the top of the draft.
  • The SyntaxHighlight boxes (e.g. § Upon creating an article) and The Earwig’s opaque (style="opacity:0.8;") signature (e.g. § Uploads disabled vs. Permission error) get above the interface in both Firefox and Chromium if, and only if, the reply’s natural (non-floating) position is above the code block/signature. The signature issue definitely looks like a browser bug, yet it occurs in both browsers…
  • Sometimes (e.g. if I use anchor links, like the ones in the table of contents), the interface may end up on the wrong side of the screen (i.e. at the bottom instead of at the top or vice versa).
APerson removed a subscriber: APerson.Mon, Feb 15, 6:33 AM