Page MenuHomePhabricator

Add a link: edit summary and publish
Open, MediumPublic

Description

If the user has chosen "yes" or "no" on any of the link suggestions, then after the user selects the "Publish" button (which may say "Submit" if they have not chosen "yes" for any links), they get the edit summary dialog. If they have not chosen "yes" or "no", and have only skipped the suggestions, the publish button will not be active, and so the user can't even get to this state.

  • Overall
    • This special edit summary shares little with the default edit summary in the visual editor. The only components that remain the same are the header, cancellation "X", and publish buttons, the disclaimer about Terms of Use, and the "Review your changes" button.
    • It does not contain any free text field for an edit summary, or checkboxes for "watch this page" or "minor edit".
  • Header
    • Just as it usually does, the header should contain a back arrow to close it (mobile) or an "X" to close it (desktop).
    • Just as it usually does, the header should say, "Save your changes".
    • If the user has chosen "yes" on any suggestions, the publish button should say, "Publish" (mobile) or "Publish changes" (desktop), just like it usually does.
    • If the user has not chosen "yes" on any suggestions, the publish should say, "Submit".
  • Body
    • Header: "Summary"
    • Below the header should be a table summarizing the work the user did in the task. It should have two columns.
      • Suggestion column
        • Header: robot icon followed by "Suggestion".
        • Each row should show, for each suggestion in the order presented in the article: the link text, followed by an arrow, followed by a "link" icon, followed by the link target. E.g. "stovetop --> 🔗 stovetop"
      • Linked column
        • Header: "Linked?"
        • If the user accepted the suggestion: blue checkmark.
        • If the user rejected the suggestion: red X.
        • If the user skipped the suggestion: gray dash.
    • Below the table is where we put the publishing disclaimer which is unique to each wiki: "By publishing changes, you agree to the..."
  • Footer
    • If the user has chosen "yes" for any links, then just as it usually does, the footer should have a "Review your changes" button. This should open up the visual diff review, just like it usually does.
    • If the user has not chosen "yes" for any links, then that button should not be present.
  • Publishing
    • If the user has chosen "yes" for any links, then those changes should be published to the wiki with an edit summary that reads like this: "Link suggestions: 7 accepted, 2 rejected, 1 skipped."
    • If the user has chosen "yes" for any links, the page should be automatically added to the user's watchlist.
    • If the user has not chosen "yes" for any of the links, then nothing gets published to the article.
    • No matter what the user has and has not chosen, a log entry gets created per T266473.
Mobile mockups as of 2021-05-03 (updated title):
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

Instrumentation

See T278118: Instrumentation: Edit summary for details.

Event Timeline

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

MMiller_WMF renamed this task from Add a link: edit summary to Add a link: edit summary and publish.Jan 22 2021, 1:46 AM
MMiller_WMF updated the task description. (Show Details)
MMiller_WMF updated the task description. (Show Details)

@Tgr @Trizek-WMF -- I'm wondering what you think of this specification I added:

If the user has chosen "yes" for any links, the page should be automatically added to the user's watchlist.

I believe that by default, pages are not added to a user's watchlist unless they check the box in the edit summary. And there is also the Preference that allows the user to have that box checked by default. Most of the newcomers won't have that preference switched on, and there is no checkbox in the edit summary that we'll be building. So I think it is good to err on the side of adding to the watchlist, so that users could see if they are reverted or expanded upon, and therefore continue to stay involved. But is this invasive; signing users up to receive notifications that they didn't explicitly say they wanted?

Editing pages won't trigger any notifications - only revert, review, and, of course, mention. Revert notifications are enabled by default. Overall, having the "Add pages and files I edit to my watchlist" option enabled by default seems like a good idea to me.

Getting an email for each page you have on your watchlist being edited is not a default features IIRC?

These email may be invasive if people edit multiple articles that have some high editing movement. However, you won't get more emails if you don't visit the page that has been edited.

Until we know that there is a net benefit to have edited mages being added to the watchlist, I would keep the watchlist option as it is now: a documented option offered when people save the page.

Agreed that it doesn't feel invasive, it might annoy some more experienced users who'd want to use the feature, though.

Editing pages won't trigger any notifications - only revert, review, and, of course, mention. Revert notifications are enabled by default.

Revert notifications are not enabled by default, FWIW.

Agreed that it doesn't feel invasive, it might annoy some more experienced users who'd want to use the feature, though.

Editing pages won't trigger any notifications - only revert, review, and, of course, mention. Revert notifications are enabled by default.

Revert notifications are not enabled by default, FWIW.

Yes, you're right. I was confused with "Restore all default settings (in all sections)" option which makes "Edit reverts" notification checked even for those users who never had it checked.

kostajh triaged this task as Medium priority.Tue, Apr 13, 2:11 PM
kostajh moved this task from April 5 - April 9 to April 12 - April 16 on the Add-Link board.

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

[mediawiki/extensions/GrowthExperiments@master] [WIP] Link recommendations save dialog

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

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

[oojs/ui@master] Add destructive variant for close icon

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

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

[mediawiki/extensions/GrowthExperiments@master] Add link: Open post-edit dialog for submissions with only rejections

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

@Tgr a couple of style things to fix:

Patch (mobile):

Figma (mobile):

  1. Spacing below/above Summary
  2. @RHo the "⟶" used in the patch looks different from what is in Figma, is there an icon you want us to use instead?

Patch (desktop)

Figma (desktop)

  1. @RHo the dialog title is left-aligned in Figma. In the patch, it's center aligned which is also how the user would see it if they do a regular VisualEditor edit. Should we keep with the default title alignment as is used elsewhere in regular VE?
  2. Padding needed for top and bottom of Summary
  3. Padding/line-height adjustment needed for rows in the table

@RHo as a heads up, the red X will be implemented when an OOUI change is merged in.

Change 680804 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Link recommendations save dialog

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

Change 681964 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add link: Open post-edit dialog for submissions with only rejections

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

Change 682015 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] Use ApiVisualEditorEditPostSaveHook for link-recommendations

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

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

[mediawiki/extensions/GrowthExperiments@master] Disable Submit button during structured edits with no changes

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

@Tgr a couple of style things to fix:

Patch (mobile):

Figma (mobile):

  1. Spacing below/above Summary
  2. @RHo the "⟶" used in the patch looks different from what is in Figma, is there an icon you want us to use instead?

Patch (desktop)

Figma (desktop)

Thanks for the ping @kostajh - the unicode arrow ⟶ U+27F6 is in the design. However, for that case there needs to be the left version ⟵ (U+27F5) used for RTL wikis. If this is problematic, I think it could also be fine to reduce the amount of icons here and replace the arrow with a colon instead like so:

  1. @RHo the dialog title is left-aligned in Figma. In the patch, it's center aligned which is also how the user would see it if they do a regular VisualEditor edit. Should we keep with the default title alignment as is used elsewhere in regular VE?

Let's keep the default center alignment on Desktop.

  1. Padding needed for top and bottom of Summary
  2. Padding/line-height adjustment needed for rows in the table

@RHo as a heads up, the red X will be implemented when an OOUI change is merged in.

Great, thanks!

Hm, I thought arrows get mirrored in RTL like it happens to braces, but apparently not. It's not problematic to do it manually. I'm not sure how well it will work if the wiki itself is LTR but the link is written in an RTL script (or the other way around), though.

Hm, I thought arrows get mirrored in RTL like it happens to braces, but apparently not. It's not problematic to do it manually. I'm not sure how well it will work if the wiki itself is LTR but the link is written in an RTL script (or the other way around), though.

Ah, given that is the case along with it not being the worst thing to simplify the UI with on less icon, I would be in favour of using the colon and double space afterwards instead per F34428893. What do you think?

Change 682683 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Disable Submit button during structured edits with no changes

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

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

[mediawiki/extensions/GrowthExperiments@master] Fixes for save dialog

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

Ah, given that is the case along with it not being the worst thing to simplify the UI with on less icon, I would be in favour of using the colon and double space afterwards instead per F34428893. What do you think?

Coding-wise both options are easy to implement. (Colon is script-specific but MediaWiki core already has a message for it.) I don't know enough about RTL languages to say whether one would work better than the other.

Change 683105 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Fixes for save dialog

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

Ah, given that is the case along with it not being the worst thing to simplify the UI with on less icon, I would be in favour of using the colon and double space afterwards instead per F34428893. What do you think?

Coding-wise both options are easy to implement. (Colon is script-specific but MediaWiki core already has a message for it.) I don't know enough about RTL languages to say whether one would work better than the other.

Hi @Dyolf77_WMF - as a person who reads in a RTL language, I'm wondering if you could provide your opinion about whether the colon ; or left arrow makes sense in this dialog to indicate when text is made into a wikilink:

Colon
Left arrow

Is one preferable to another, do both work about the same?

Change 681941 merged by jenkins-bot:

[oojs/ui@master] Add destructive variant for close icon

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