Page MenuHomePhabricator

Add a link: post-edit dialog
Open, MediumPublic

Description

After the user publishes (when they have chosen "yes" at least once) or submitted (when they have not chosen "yes" at least once), they go to the post-edit dialog state. This is almost exactly the same as the post-edit dialog we built for the "guidance" effort in T245790: Newcomer tasks: post-edit dialog, with a few changes.

  • The suggested task should be another "add a link" task from that user's selected topics of interest.
  • If the user had not chosen "yes" at least once:
    • The banner above the dialog should read: "Thanks for reviewing suggestions. Keep going!"
    • Instead of "Edit another suggestion:", the header in the body should read: "Next suggestion:"
    • The bottom button on the dialog, which reads, "Close and edit this article again", should just say "Close".
  • If the user dismisses the dialog, they should be in read mode.
Mobile mockups as of 2021-01-12:
Desktop mockups as of 2021-01-12:

NOTE: Refer to Figma for up-to-date detailed redline mocks and specs:
Mobile: https://www.figma.com/file/2SONd8P1tsexIB5coMOp8h/Growth-Structured-tasks?node-id=181%3A65
Desktop: https://www.figma.com/file/2SONd8P1tsexIB5coMOp8h/Growth-Structured-tasks?node-id=112%3A0

Event Timeline

@MMiller_WMF sometime this week or next could you add specifications here please?

mepps added a subscriber: mepps.

I'd like to take a look at this.

Note that there is no way to reach the dialog organically as there's no way to save an edit yet (although maybe you can switch to the normal editor and save there). To bring up the panel programmatically, you can run something like SuggestedEditSession.getInstance().showPostEditDialog({}) in the browser console on the task page.

As per T277802 - after discarding the post-edit dialog, the normal editors (VE and the source editor) would be available.

kostajh triaged this task as Medium priority.

For the Desktop the following spec is not done:

  • If the user had not chosen "yes" at least once:
    • The banner above the dialog should read: "Thanks for reviewing suggestions. Keep going!"
    • Instead of "Edit another suggestion:", the header in the body should read: "Next suggestion:"
    • The bottom button on the dialog, which reads, "Close and edit this article again", should not be present at all. There should only be one button: "View more suggested edits".

For @RHo review (other items that the spec above) - Desktop only (mobile is still WIP)

The mockup post-edit dialog and the existing post-edit dialog have several UI differences - should the existing dialog be changed to the mockup dialog?

  • "Next steps" title is centerd vs the mock-up left-aligned position
  • the buttons labels are different on the mockups
  • "Vew more suggested edits" and "Close to view..." labels are displayed as blue links in the mockup
  • there is no reload icon on the implemented post-edit dialog

Desktop post-edit dialog

mockup dialogexisting dialog

@Etonkovidova, I think @Tgr is still working on this one. (@Tgr if so please move back to in progress)

Change 683755 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Add Link: changes to post-edit dialog

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

Yeah, this wasn't implemented yet (it's just fairly similar to the existing feature). Also I think the design changes are not part of this task, the mocks include other tasks like T272664: Add a link: refresh button on post-edit dialog (nice to have).

The bottom button on the dialog, which reads, "Close and edit this article again", should not be present at all. There should only be one button: "View more suggested edits".

I'm assuming this refers to link recommendation tasks in general, not just the case where the user did not make an edit - it would be weird to offer a close option in one case but not in other. @MMiller_WMF let me know if I misunderstood.

Change 683755 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add Link: changes to post-edit dialog

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

@RHo do you want the trailing colon in Next suggestion: and Edit another suggestion:? Figma doesn't show it, but the phab description includes the colon.

Yeah, this wasn't implemented yet (it's just fairly similar to the existing feature). Also I think the design changes are not part of this task, the mocks include other tasks like T272664: Add a link: refresh button on post-edit dialog (nice to have).

The bottom button on the dialog, which reads, "Close and edit this article again", should not be present at all. There should only be one button: "View more suggested edits".

I'm assuming this refers to link recommendation tasks in general, not just the case where the user did not make an edit - it would be weird to offer a close option in one case but not in other. @MMiller_WMF let me know if I misunderstood.

My understanding is that "Close and edit this article again" button should appear for all task types. The only time it shouldn't be in the footer is if the user skipped all suggestion or said no to suggestions but didn't make an edit to the text.

@Tgr @kostajh @RHo -- thank you for questioning this. I'm thinking this through again. As @kostajh says, the original requirements are, in fact, to not have that "close and edit this article again" button if the user did not actually edit the article by choosing "yes" on any suggestions. And the reason we made that requirement is because we didn't want to say "edit this article again", because they hadn't edited it at all yet. But perhaps removing the button was not the right solution to that.

Here's what I think: let's have the button in both cases, but in the case that no edit was saved, just have different copy: "Close". That should be easier on our business rules.

How does that sound? If good, I'll update the task description.

In terms of code complexity, it doesn't make much difference, all the options are trivial to implement. But I think it would feel confusing to me as a user if the "close" option would sometimes appear and sometimes not; whether the user accepted any recommendations does not have much to do with whether they might want to interact more with the article. (And there are other ways than the button to close the dialog, so removing the button doesn't remove the complexity of how to handle if the user clicks "Edit" again.)

Always having the buttons is the most consistent option so it sounds good to me.

Change 684041 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GrowthExperiments@master] Fix postedit dialog button logic

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

Change 684041 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Fix postedit dialog button logic

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

@RHo (@MMiller_WMF) The dialog with 'Close' button doesn't appear on mobile at all - did I miss that the spec for mobile was different?
For review

  • the font color for buttons is different on Desktop and mobile -it's different from the mockup
  • I agree with @Tgr comment:

In terms of code complexity, it doesn't make much difference, all the options are trivial to implement. But I think it would feel confusing to me as a user if the "close" option would sometimes appear and sometimes not; whether the user accepted any recommendations does not have much to do with whether they might want to interact more with the article. (And there are other ways than the button to close the dialog, so removing the button doesn't remove the complexity of how to handle if the user clicks "Edit" again.)

Always having the buttons is the most consistent option so it sounds good to me.

The way it works now:

AnswersPost-edit dialog
Desktopall skipped
'yes'
'no'
AnswersPost-edit dialog
Mobileall skipped the Post-edit dialog is not displayed
'yes'
'no'

Thanks @Etonkovidova and @Tgr. I agree about having the Close button for both cases (whether links were added or not), but a few very minor UI fixes based on your review and screenshots below, and this is ready to close:

  • Level and Robot icon in the dialog is larger than the expected 16x16dp
  • Pageviews should be removed from the next suggested article card.

@RHo (@MMiller_WMF) The dialog with 'Close' button doesn't appear on mobile at all - did I miss that the spec for mobile was different?
For review

  • the font color for buttons is different on Desktop and mobile -it's different from the mockup
  • I am guess it's cos mobile uses a more custom drawer element, whilst the Desktop uses a standard dialog with neutral buttton colour, so I'm OK to keep the different colours until we have a more standardised drawer component (and have updated the Desktop spec accordingly)
  • I agree with @Tgr comment:

In terms of code complexity, it doesn't make much difference, all the options are trivial to implement. But I think it would feel confusing to me as a user if the "close" option would sometimes appear and sometimes not; whether the user accepted any recommendations does not have much to do with whether they might want to interact more with the article. (And there are other ways than the button to close the dialog, so removing the button doesn't remove the complexity of how to handle if the user clicks "Edit" again.)

Always having the buttons is the most consistent option so it sounds good to me.

The way it works now:

AnswersPost-edit dialog
Desktopall skipped
'yes'
'no'
AnswersPost-edit dialog
Mobileall skipped the Post-edit dialog is not displayed
'yes'
'no'

@Tgr @Etonkovidova -- if the user skips all suggestions on mobile, there should be a post-edit dialog. Let's add that.

And we are all agreed about the changes for the "close" button -- it should always be there, just with different wording if the user has or has not skipped all suggestions. The task description is up-to-date with this specification.

  • I am guess it's cos mobile uses a more custom drawer element, whilst the Desktop uses a standard dialog with neutral buttton colour, so I'm OK to keep the different colours until we have a more standardised drawer component (and have updated the Desktop spec accordingly)

We specifically override the button color to be progressive on mobile and blackish on desktop, IIRC that was part of the design in T245790: Newcomer tasks: post-edit dialog (to keep with how other buttons look on desktop/mobile, I imagine?). Easy to change if preferred.

@Tgr @Etonkovidova -- if the user skips all suggestions on mobile, there should be a post-edit dialog. Let's add that.

As we since discussed elsewhere, that's T282546: AddLink: Skipped all dialog throws exception on ve.init.target.tryTeardown.then on mobile.

And we are all agreed about the changes for the "close" button -- it should always be there, just with different wording if the user has or has not skipped all suggestions. The task description is up-to-date with this specification.

So it seems like on mobile a no-change save is not recognized as such. (We should check whether we also get that wrong in the instrumentation or just in the dialog config. The dialog is set up very differently on mobile since it reloads the page after an edit, so it's more likely the latter.)

So what's left in this task is that, plus these:

  • Level and Robot icon in the dialog is larger than the expected 16x16dp
  • Pageviews should be removed from the next suggested article card.