After the user saves a suggested edit, they should see a special "post-edit dialog".
User job stories
When I have completed the suggested edit...
I want feedback that my edit was good, so that I feel encouraged to do more editing.
I want confirmation that my edit was accepted, so that I can move on to whatever is next.
I want some direction on what I can do next, so that I know how to keep contributing.
Prototypes
The post-edit dialogs can be seen in these prototypes, after clicking through the whole workflow, modifying the text in the article, and saving an edit:
For easier reference, here are screenshots from the desktop and mobile prototypes as of 2020-04-20:
Desktop  | Mobile  |
Difference between first edit to an article and successive edits to that same article on mobile:
Successive edits to an article on desktop:
When it is shown
Specifically, the post-edit dialog should be shown when the user successfully saves an edit on a page that they arrived on from the suggested edits module on the homepage or from the post-edit dialog of a previous suggested edit. It should only happen if the user arrives from clicking on a suggestion in one of those locations -- not if they navigate to the article some other way, or are returning to the article after leaving. These are the same rules as when the guidance help panel should appear, described in T244431: Newcomer tasks: guidance panel behavior.
The dialog should appear after successive edits on the same article during the same session. This is because it is common for users to make multiple small edits to the same article all in a row, and we want them to have the dialog's options after each one. The dialog will look a little different if it is being shown for a second time on the same article. See below.
Other post-edit notices
This post-edit dialog should be the only thing that appears after the user saves an edit in this way -- it should override any other post-edit toasts or notices.
Two components
The post-edit dialog consists of two visual pieces: a box with links and information and a banner along the top of that box. The two components should animate together up from the bottom of the screen.
Box component
Desktop
- This should be a box in the center of the page.
- It should have an "X" that closes it and leaves the user on the article in read mode. It should also close if the user clicks away from it.
- Header: "Next steps"
- Body
- Header: "Edit another suggestion:"
- Followed by a horizontal version of the suggestion card that the user sees in the suggested edits module
- Desktop: should contain a preview image, article title, wikidata description (kept to one line), pageview count, and task type. It should not contain a preview of the text, an explanation of the task type, difficulty level, or tooltip.
- Mobile: should contain a preview image, article title, wikidata description (kept to one line), difficulty level, and task type. Unlike desktop, it should not contain pageview count. It should also not contain a preview of the text, an explanation of the task type, difficulty level, or tooltip.
- If we find it difficult to make a new shape of preview card, we could see what the box looks like when we use the same vertical card as the suggested edits module.
- The single suggestion should match whatever the user's current topic and difficulty settings are in the suggested edits module. It can be whatever was next in the queue, or a new search, or whatever works to get one suggestion.
- When the user clicks it, they should go to that article just as if they had arrived there from the suggested edits module on the homepage, and should receive the guidance experience there.
*** This card should not appear when the dialog is shown after a successive edit on an article in the same session. In other words, if a user edits a suggested article, they should see the dialog with the card. If they dismiss the dialog and edit the same article again, when the dialog reappears, it should not have this card. Rule change per T255388#6229822
- This card should not appear (even on their first edit to the article) when there are no more suggestions available for the user under their current filter settings, or in any case of not being able to bring up a suggestion.
- Footer: contains two buttons. On desktop these buttons are black, and on mobile they are blue -- in line with default styling.
- "View more suggested edits". On desktop, this should be a link to the homepage. On mobile, it should be a link to the suggested edits module.
- "Edit this article again". This closes the dialog, and then the user can open the editor again if they want.
Mobile
- Rather than a box in the center of the page like on desktop, this should be a drawer at the bottom of the screen.
- It should have essentially the same behavior as the "mobile peek" in T244434: Newcomer tasks: guidance mobile peek. It should animate from the bottom and cause the screen behind it to have a transparent white layer.
- In terms of contents, it should have the contents described above for desktop, except when deviations for mobile are stated.
Banner component
Desktop
This component should be shown right above the box. They always go together.
It's similar to the post-edit toast that currently appears on desktop on many Wikipedias that looks like this:
But it is different in several ways:
- It has different coloring.
- The text should read as follows. It is different depending on whether the edit is falling under FlaggedRevisions:
- No FlaggedRevisions: "You've published an edit! Thanks and keep going!"
- FlaggedRevisions: "You've saved an edit! Thanks and keep going!"
- It does not disappear after any amount of time -- it only disappears when the user dismisses the box below it or other navigates away.
Mobile
This is quite different from the post-edit toast that currently appears on mobile that looks like this:
- It has different coloring.
- The text should read as follows. It is different depending on whether the edit is falling under FlaggedRevisions:
- No FlaggedRevisions: "You've published an edit! Thanks and keep going!"
- FlaggedRevisions: "You've saved an edit! Thanks and keep going!"
- It animates up from the bottom of the screen along with the drawer component beneath it.
- It does not disappear after any amount of time -- it only disappears when the user dismisses the box below it or other navigates away.
Note
In the future, we may want to repurpose this feature, or build something similar, for T244930: Newcomer tasks: post-edit nurture for non-suggested edits.
Instrumentation
Below are the portions of our instrumentation plan that relate to this component. See T246919: Newcomer tasks: guidance instrumentation for the full plan.
- impression: we want to record that the user received the post-edit dialog. Because this dialog will contain a next article suggestion, we want to record the same details of that article suggestion that we record in se-task-impression events (e.g. title, whether it has an image, task type, maintenance template, etc.), while also recording that they received the impression via this post-edit dialog, as opposed to from the suggested edits module.
- close: whether the user clicks away or clicks the “X” to dismiss the dialog.
- clicks: whether the user clicks the link to go to their homepage or the link to continue editing the article.
- task click: if the user clicks the suggested article, we want to record that click event along with the article details, similar to se-task-click events on the homepage, but specifying that they clicked via this post-edit dialog, as opposed to from the suggested edits module.
- homepage visit: in the homepageVisit schema, we record the referer_route. We should add a referer_route for arriving on the homepage via the link in the post-edit dialog.
- Note: instrumentation should include the task type (for the edit just saved), the user's task type / topic filter preferences, and the type of editor used for the edit (which is part of the HelpPanel schema anyway).
