Page MenuHomePhabricator

Notify people when new comment(s) is posted in a discussion while they are composing a reply, and offer to show it
Closed, ResolvedPublic

Description

When the handling of edit conflicts on busy pages is good, editors can Reply without even noticing that someone else had just replied to the same comment. Should we notify them when this happens? Would it be possible to differentiate between a relevant edit conflict (same conversation) and edit conflicts elsewhere on the page?

Story

As someone who is drafting a comment using the Reply Tool, I want to know when someone changes the content of the discussion I am drafting a comment within, and what they have changed, so that I can decide whether or not to make changes to the comment I'm drafting prior to publishing it.

Requirements

META

  • Platforms: Desktop + Mobile
  • Editing Interfaces: Reply Tool
    • Note: any implementation should preserve us the option to extend this experience to other VE-based experiences (e.g. New Topic Tool, VE, 2017 WTE)

USER EXPERIENCE

  1. Inform people the state of the discussion has changed
    • The moment a qualifying change has been made, show an alert in/ around the Reply Tool informing people that the page has changed from the version they are looking at.
      • Where "qualifying change" in this context means someone else posts new comment(s) in the discussion (read: == H2==) the person is drafting a comment within at any point after the talk page was loaded.
      • Note: we will consider improvements to the change detection scope in T300216.
    • One alert should be shown regardless of the number of new comments that have been posted in the time after the talk page was loaded and you opened the Reply Tool. Said another way: if after you open the Reply Tool, two new comments are posted in the discussion you are in, only show one alert.
    • The alert should be implemented such that it appears in peoples' peripheral vision...the kind of alert that people will notice if they are paying close attention
  1. Offer people the opportunity to see what's changed or to explicitly forego this opportunity
    • The "alert" mentioned above ought to contain affordances that enable people to:
      • Show the change(s) that have been made to the discussion in the time between you opened the Reply Tool and "this" moment
      • Forego the opportunity to see what changes have been to the discussion
  1. If people opt to see what's changed in the discussion, ensure whatever content they've drafted within the Reply Tool is retained/recovered/saved
    • Don't reload the page, just update the contents via the API and keep the comment you've drafted in memory. @Esanders can speak to this in detail.
  1. If people forego the opportunity to see what's changed in the discussion, ensure they can return to what they were doing prior to the alert appearing This will be designed and implemented as part of T300560.
    • Upon opting NOT to see how the discussion has changed, people should see the alert disappear and all other aspects of the page, the Reply Tool, and the content within the Reply Tool unchanged.
      • Note: if a new comment(s) is posted *after* someone dismisses the initial alert, another alert should be shown.
NOTE: "5." and "6." (below) will be implemented in T300215 as part of "version 2" of this functionality.
  1. Help people to easily locate what's changed within the discussion
    • Upon opting to see how the discussion has changed, people should see the page update with the comment(s) that have been changed highlighted ephemerally
  1. Help people resume writing/editing the comment they started
    • In updating the page to its latest state, people need to be able to immediately locate the Reply Tool with the comment they drafted prior to the discussion being updated in tact.

Open questions

  • 1. How might we go about detecting edits to a specific section?
    • We decided NOT to answer this question for now in favor surfacing alerts when new comments are posted within a specific discussion. We will answer this question if/when we prioritize work on T300216.
  • 2. What do we do to visually communicate when content has been deleted?
    • We will address this question as part of T300215.
  • 3. What happens when additional changes are made to the discussion after the first alert is shown and before you engage with said alert?
    • As is noted in "1.", one alert should be shown no matter how many new comments are published in the time between an initial new comment is posted and when someone engages with the alert.

References


Approaches

This section contains an in-progress list of potential approaches to addressing the need(s) this ticket is "asking" to be met.

  1. Re-use MediaWiki's existing edit conflict detection mechanism
    • Volunteer Experience
      • i. Someone clicks/taps the Reply button within the Reply Tool
      • ii. Edit conflict detection mechanism checks whether the page's state has changed in the time between this moment and when the person opened the Reply Tool in "i."
      • iii. If the edit conflict mechanism detects a change, a warning will appear within the Reply Tool informing people that an edit conflict could result from proceeding to publish the comment they drafted
    • Considerations
      • There are likely to be many false positives with this approach considering the existing edit conflict detection mechanism does not consider what part of the page might've changed.
    • Complexity
      • Relatively straightforward considering we'd be re-using and integrating existing functionality
  1. Introduce a new, more targeted, edit conflict detection mechanism
    • Volunteer Experience
      • i. Someone clicks/taps the Reply button within the Reply Tool
      • ii. The "new, more targeted" edit conflict detection mechanism begins checking for changes in the state of the section in which the person is drafting a comment within
      • iii. If the "new, more targeted" edit conflict mechanism detects a change, a warning will appear within the Reply Tool informing people that proceeding to publish the comment they are drafting will result in an edit conflict
    • Considerations
      • What happens if/when the comment to which you are directly replying to in "i." gets deleted?
      • How confident can the software be that an edit conflict will result from the person proceeding to publish they are drafting?
    • Complexity
      • More complex considering we'd be introducing a new mechanism that "bounds" detection to the specific section someone is posting a comment to/within

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I was about to report the same issue. The automatic edit conflict resolution is quite annoying indeed. This needs to be worked on.

To summarize the ideal situation:

If there is an edit conflict, then:

  • You don't want automatic resolution if your comment will seem redundant to people who read the conversation later. For example, imagine that I ask where a page is. Two people both write "Here's the link". You want the second person to be told that another editor has already replied, so the second person can cancel the redundant comment.
  • You want automatic resolution in every other case, including:
    • The edit conflict is due to someone editing the comment you're replying to
    • Any sort of vote or poll (because saying the same thing is not redundant)
    • Your comment has different content (e.g., two editors who recommend different links, two editors replying to different parts of the conversation)

I don't know whether detecting these situations would be practical, but is that a reasonable description of the ideal?

Also, how often do you wish that an edit conflict hadn't been automatically resolved? Once a week? Once a month? Once a year?

@Whatamidoing-WMF

You don't want automatic resolution if your comment will seem redundant to people who read the conversation later.

I totally agree.

The edit conflict is due to someone editing the comment you're replying to

Actually, I wouldn't like the automatic resolution in those cases. Sometimes the initial comment changes a lot, moreover changes are hard to detect.

I agree on the other cases you pointed out.

Also, how often do you wish that an edit conflict hadn't been automatically resolved? Once a week? Once a month? Once a year?

Every time there is a conflict that needs my attention. There's no problem, even if it happens every day.

(Added the ===Approaches section to the task description based on the ideas @DLynch + @matmarex entered during the team's 29-Sep team meeting)

  • Considerations
    • There are likely to be many false positives with this approach considering the existing edit conflict detection mechanism does not consider what part of the page might've changed.

As far as I know, it does consider what parts of the page changed: MediaWiki core tries to merge parallel edits, an edit conflict occurs only when it fails. This means that comments in different topics are likely not to result in an edit conflict; even parallelly written comments in the same topic might not cause an edit conflict if the comments are sufficiently far from each other.

By the way, both solutions mention only edits made after the reply tool has been opened. However, conflicts can occur also between the page load and the time the reply tool is opened. (They’re possible, especially if the browser tab has been open for some time by the time one clicks the reply link.) What about them?

As I understand it, MediaWiki's built-in edit conflict behavior will display the conflict if you've added/removed/changes any lines of text within 3 lines of someone else's addition/removal/change, and automatically resolve the conflict otherwise (roughly… diffs are hard, I'd have to learn more to describe it precisely). Our current edit conflict behavior will always automatically resolve the conflict.

The question now is, when should we display the conflict instead?

  • We definitely want to display it if someone else replied to the same comment as you (I think this is uncontroversial, but please let me know if it's not)
  • We definitely don't want to display it if someone else commented in a different top-level section than you (see above)
  • We may or may not want to display it if they reply to a different comment in the same section, or if one of the users is replying in a subsection

I don't know what we should do in the last case (or maybe there are other interesting cases), I'd love to hear some thoughts about it.


I've started working on this, but mostly just thinking and experimenting for now, maybe I'll have some functional demo next week. I'd like it to look basically like this mockup:

image.png (2×3 px, 738 KB)

(mockup of a real example conflict that annoyed me this evening, and it's the second one this month despite my rare usage of talk pages… subscribing to notifications for sure seems to increase my chances of running into this problem)


I also want to integrate this interface with our behavior on old revisions (T269388, basically adding a way to show all recent comments without leaving the page) and "double-posting protection", a.k.a. edit conflicts with yourself (T286409). Not sure yet how, but it seems closely related.

Similar features exist in Phabricator and Gmail (where there is only ever one thread per page). I agree that the best approach would be a non-modal warning that new comments have been published in the same section with the option to non-destructively reload the page, preserving your unpublished comment.

Phab and Gmail are probably using push notifications, which we don't have the infrastructure for. Instead we would have to choose between

  • checking before submit
    • this requires us to stop the submit when changes are present which could be annoying on very active pages
  • polling every X seconds for new changes
    • we would probably want to detect inactive tabs to avoid wasting bandwidth
Gmail: new message from USER Show IgnorePhabricator: Page updated, click to reload
image.png (436×687 px, 79 KB)
image.png (273×431 px, 17 KB)

(I pushed some experimental code in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/732000, but this is nowhere near done and I won't have time to work on it soon, sorry.)

Note: as I gather more information en route to requirements, I've added this ticket as a blocker to T296645 in order to hold us accountable to explicitly deciding whether we will address this issue before or after the en.wiki opt-out deployment.

Update: Draft requirements posted
Today, @Esanders and I started sketching out the user experience for what this could look like and I've now updated the task description to reflect what Ed and I talked about.

You'll notice the experience in the newly-created ===Requirements section hews closely to Approach #2: Introduce a new, more targeted, edit conflict detection mechanism and incorporates the ideas @DLynch, @ValeJappo, @Tacsipacsi, @Whatamidoing-WMF, and @matmarex have shared.

Next, the Editing Team will discuss the feasibility of implementing what's currently described in the ===Requirements section. In the meantime, we would value knowing what – if any – thoughts/questions/concerns the user experience, as it's currently described, brings to mind.

The "polling every X seconds for new changes" approach, if it's not too resource-greedy, appeals, since the sooner I know someone else has commented, the sooner I can start adapting mine to whatever they said. It'd be even better if there's an easy way to load their comment without feeling like the software is going to discard mine.

Most-expansively, to detect it, we could merge in something like this API patch (which exposes our parsed comment tree) and diff the tree between what's on-page and on-server. It'd be a minimal diff process that only cares about the subset of the current thread: find the currently replied-to comment and check whether it has the same replies; if the replied-to comment doesn't exist that's a major conflict; if the replies differ that's something we can prompt to display with the data from the API; special-case a check for "the current user has added a reply that doesn't exist on the local page" to catch double-posts after an error, maybe. We'd need to immediately check it when the reply widget is opened, and then we could fairly-infrequently poll while the reply is being written.

Advantage of this approach is that we can easily avoid being confused by revisions affecting other sections, and it's robust against minor changes to surrounding content. Disadvantage is that we'd be requesting the fully parsed discussion from the server pretty frequently, and so we might want to invest in optimizing/caching that.

Also, how often do you wish that an edit conflict hadn't been automatically resolved? Once a week? Once a month? Once a year?

Every time there is a conflict that needs my attention. There's no problem, even if it happens every day.

@ValeJappo, I'm not asking about the future. I want to know how often automatic conflict resolution has already caused a problem.

I believe that the automatic conflict resolution has been running for more than one year. During that time, I think I have regretted the resolution about 5 times – definitely less than 10 times. I have been happy about it many times.

Is your experience very different from mine?

@DLynch, someone else replying to the comment would be something I'd want to know, but so would someone else replying at the same level as the comment I'm replying to. In other words, sometimes replies happen by indenting a level further, but sometimes they happen by just making another comment at the same indentation level.

Update: Draft requirements posted
Next, the Editing Team will discuss the feasibility of implementing what's currently described in the ===Requirements section. In the meantime, we would value knowing what – if any – thoughts/questions/concerns the user experience, as it's currently described, brings to mind.

Today, the Editing Team met to discuss the above and converged on the following plan...

  1. We are going to split up this feature into two iterations:
    • First iteration (T250295): introduce functionality that alerts people, in real-time, when a new comment is posted within the same discussion read (== H2 ==) they are drafting a comment within.
      • This functionality is described in Steps 1, 2, 3, and 4 within the description's === Requirements section.
    • Second iteration (T300215): introduce functionality that makes it easier for people locate the specific comment(s) that have been changed.
      • This functionality is described in Steps 5 and 6 within the description's === Requirements section.
  2. To start, we are going to surface alerts within the Reply Tool when a new comment is posted within the same discussion read (== H2 ==) people are drafting a comment within.
    • Thinking: while we consider alerting people when *any change/edit* is made to content within the *discussion* or *thread* they are commenting within, this level of precision will require more effort to implement. As such, we decided to start with offering "new comment" detection as a way of incrementally offering people more awareness of changes to the discussion they are participating in. If/when this level of precision proves to be insufficient, we'll prioritize work on: T300216.

Before beginning implementation, we'll share a version of the above on-wiki in order to learn whether we ought to reconsider any of the assumptions in the above.

In the meantime, I've updated the task description to reflect the above.

ppelberg renamed this task from Should we display a note about automatically resolving an edit conflict? to Alert people when new comment(s) posted in a discussion they are replying within.Jan 27 2022, 12:00 AM
ppelberg claimed this task.
ppelberg updated the task description. (Show Details)

Before beginning implementation, we'll share a version of the above on-wiki in order to learn whether we ought to reconsider any of the assumptions in the above.

See: mw:Topic:Wov6fz5lqmm3nl3p.

Esanders renamed this task from Alert people when new comment(s) posted in a discussion they are replying within to Alert people when new comment(s) are posted in a discussion while they are composing a reply.Jan 27 2022, 12:19 PM
ppelberg added a project: Goal.
Esanders renamed this task from Alert people when new comment(s) are posted in a discussion while they are composing a reply to Notify people when new comment(s) is posted in a discussion while they are composing a reply, and offer to show it.Jan 31 2022, 1:28 PM

The tricky part for notifying and how many details to show is that someone might have opened the page yesterday and then decided to click reply today, and so they'll suddenly get told about all 150 comments on a very busy page at once. (Of course, most discussions won't be that busy.)

I, of course, would *never* leave tabs open for weeks at a time to remind myself that I should maybe respond to something eventually...

Note: as I gather more information en route to requirements, I've added this ticket as a blocker to T296645 in order to hold us accountable to explicitly deciding whether we will address this issue before or after the en.wiki opt-out deployment.

Update: while the Editing Team is actively working on this task, we do not currently consider this as blocking the deployment of the Reply Tool at en.wiki

After discussion today, this feature is will initially be disabled on mobile due to our inability to safely refresh content in MobileFrontend. An alternative approach would be to refresh the whole page on mobile, with the small risk that sessionStorage fails for some unknown reason.

After discussion today, this feature is will initially be disabled on mobile due to our inability to safely refresh content in MobileFrontend.

Here is a ticket for implementing this functionality on mobile: T301929.

An alternative approach would be to refresh the whole page on mobile, with the small risk that sessionStorage fails for some unknown reason.

In the meantime, @Esanders are you able to describe scenarios in which sessionStorage could fail? And, if possible, what you think the probability of those failures occurring to be? I ask this is an effort to decide whether blocking T301929 on T219420 is worthwhile.

sessionStorage could fail if it's disabled (generally lumped into cookie-blocking, I think), or if the storage is full (the size limit on the storage is 5mb-per-origin-per-session).

Disabled is probably more likely... but someone who's disabling all cookies on wikipedia is probably used to having an inconsistent experience.

The storage being full is possible, but I think very unlikely. Absent a mediawiki (or extension) bug filling the storage up with junk, you'd have to edit a lot of very large comments to even get close. (The storage includes the transaction history, so you could deliberately trigger this by e.g. repeatedly pasting in and deleting a large article.)

sessionStorage could fail if it's disabled (generally lumped into cookie-blocking, I think), or if the storage is full (the size limit on the storage is 5mb-per-origin-per-session).

Note that the current patch does not rely on sessionStorage as we created a wrapper that duplicates the contents of sessionStorage into memory, so even if sessionStorage is disabled we will always recover your comment when doing a dynamic update.

We've merged the patches implementing this (see subtasks), and the feature will be included in this week's release. T301582 and T300560 are not done yet, but they are not really blockers.

In the discussion at https://www.mediawiki.org/wiki/Topic:Wq2ekwwt65nu3mp2 Valereee has suggested making the warnings about edit conflicts be opt-in, and specifically that they be turned off for new editors. The benefit to new editors (<100 edits, so 99% of accounts?) is likely to be much lower, and the anxiety about what's going on (did I break something? Am I doing this wrong?) is likely to be higher.

The requirement for people being able to dismiss the alert has not been implemented and also there are some issues with highlight being persistent when someone clicks on those alerts to show the new comments. Awaiting @ppelberg's response on Slack.

ppelberg updated the task description. (Show Details)