Page MenuHomePhabricator

[EditCheck Feedback] Order of checks presented when clicking on "Revise" on Tone Check on mobile
Closed, ResolvedPublic

Description

When pasting some content from an external website that is also tone violating it activates paste check on mid-edit and tone-check on both in mid-edit (on cursor-off to a different paragraph) and pre-save mode. In this scenario, if someone clicks on "Revise" on tone check dialog, it takes user back to the mid-edit mode, but it shows the paste-check first.

Would it be possible to show the tone check first to tie it with the action that has just been taken from pre-save (clicking on "Revise")? Might help to create an experience of continuation of the workflow.


Requirements

When someone pastes content that causes both Paste Check and Tone Check to activate, and then proceeds to the Pre-save without addressing either, when they tap the Revise revise button in the Tone Check dialog, they should be returned the Mid-edit moment with Tone Check focused and in its revising state.

In addition to the above, Paste Check should be collapsed and shown after someone resolves or dismisses the Tone Check they will have seen immediately upon landing back in the Mid-edit moment.

Acceptance criteria

Tone Check prioritized after “Revise”
  1. Given a user pastes content that triggers both Paste Check and Tone Check,
  2. And the user clicks “Publish changes,”
  3. And the pre-save Tone Check dialog appears,
  4. When the user clicks “Revise,”
  5. Then the editor should reopen in mid-edit with Tone Check surfaced first.
AC2 — Paste Check deferred, not dropped
  1. Given the above scenario,
  2. When the user returns to mid-edit via tapping “Revise,”
  3. Then Paste Check should not appear before Tone Check,
  4. But should remain eligible and queued.
AC3 — Paste Check appears after Tone Check
  1. Given Paste Check was deferred,
  2. When the user resolves or dismisses Tone Check,
  3. Then Paste Check should be surfaced.
WARNING: @ppelberg used an LLM to generate the acceptance criteria above as an experiment to learn the extent to which this is helpful.

Event Timeline

Interesting -- we deliberately force paste to go first currently, but we weren't thinking about the mode switch when we did that.

Change #1249403 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] EditCheckController: if a refresh is ongoing return the same promise

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

Change #1249404 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/VisualEditor@master] ToneCheck: don't lose state when transitioning back from pre-save

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

Change #1249403 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] EditCheckController: option to join in on an existing refresh

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

Change #1249404 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] ToneCheck: don't lose state when transitioning back from pre-save

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

On Desktop, Paste Check dialog remains collapsed (Not Expanded) after resolving or dismissing the Tone Check.
On Mobile, Paste Check now correctly gets deferred when Revise button was clicked in pre-save button , and it surfaces up in non-collapsed way whenever it's position in the queue is current.

On Desktop, Paste Check dialog remains collapsed (Not Expanded) after resolving or dismissing the Tone Check.
On Mobile, Paste Check now correctly gets deferred when Revise button was clicked in pre-save button , and it surfaces up in non-collapsed way whenever it's position in the queue is current.

Thank you, @Ryasmeen.

Next steps

  • Editing Engineering to investigate (and hopefully, fix) the desktop UX such that Paste Check gets expanded after someone resolves or dismisses Tone Check in mid-edit

Worth noting that currently this is impossible to experience because, since we closed the a/b test, Tone is configured as being suggestion-only. To experience anything like this you need to go and add this to your MediaWiki:editcheck-config.json:

	"tone": {
		"showAsCheck": true
	},

Or use the ecenable=experimental parameter.

Anyway, current sequence of events:

  1. Paste something tone-violating. To keep it simple, paste it into an existing paragraph so you don't also get shown the add-reference check.
  2. Paste check will be shown, in mid-edit. (But not tone check, because you haven't yet moved to a different branch node.)
  3. Choose to publish.
  4. Tone check will be shown, in pre-save. (But not paste check, because paste check only shows mid-edit.)
  5. Choose "revise".
  6. You will be back in the mid-edit mode, with the tone check focused and in the revising state (blue border).
  7. Resolve-or-dismiss the tone check.
  8. You will still be in mid-edit, with no checks focused.

I.e. all the acceptance criteria but AC3 are currently met.

Are the criteria actually paste-specific? The issue here seems to be that because we lose the selection in the surface, there's no focused check to be shown. Mobile doesn't experience the same, because it keeps the drawer for that section-of-checks open.

I.e. all the acceptance criteria but AC3 are currently met.

Are the criteria actually paste-specific? The issue here seems to be that because we lose the selection in the surface, there's no focused check to be shown. Mobile doesn't experience the same, because it keeps the drawer for that section-of-checks open.

I propose that we consider this task resolved and use the newly-created T421424 to address AC3: Paste Check unexpectedly not appearing once addressing a Tone Check in mid-edit via the pre-save moment.