Page MenuHomePhabricator

Newcomer tasks: post-edit dialog
Closed, ResolvedPublic

Description

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:

NOTE: Those prototypes are not exactly up-to-date anymore. The canonical version can be found in Zeplin. Redlined design specs are in the Growth Zeplin board for the relevant screens tagged "Guidance v1.2"
NOTE: wording written in the task description overrides wording in the mockups.

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.

[..] The user gets the same post-edit dialog after every edit. Per our discussion in retro today, I think this will simplify the code, and also de-confuse the user, who may be wondering why they sometimes get a next suggestion and sometimes don't.

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).

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
RHo updated the task description. (Show Details)Apr 20 2020, 2:35 PM
RHo added a comment.Apr 20 2020, 2:38 PM

@RHo just to doublecheck, no article description text is needed, right? The task description says "It should not contain a preview of the text" but the Zeplin design has what seems to be the Wikidata description.

Yes, good catch. I've updated the task description to clarify that is contains the Wikidata description, with it overflowing into an ellipsis when it is longer than one line.
.

Tgr added a comment.Apr 20 2020, 2:38 PM

@RHo the mobile Zeplin mock does not have pageview numbers, is that an accident or intentional to save space?

RHo added a comment.Apr 20 2020, 2:41 PM

@RHo the mobile Zeplin mock does not have pageview numbers, is that an accident or intentional to save space?

This is intentional to save space. The idea is also that we will re-use this compact article card design as the 'list' view on a later variant of the Suggested edits results.

Tgr added a comment.Apr 20 2020, 2:44 PM

Makes sense, thanks!

Change 592501 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Display post-edit dialog widget

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

MMiller_WMF updated the task description. (Show Details)Apr 26 2020, 10:00 PM

@RHo @Tgr -- I updated the task description to cover everything we decided and changed above. That includes:

  • The banner will save "You've saved an edit!" instead of "You successfully published an edit!" At @Dyolf77_WMF's suggestion, this should be an eas way to cover the FlaggedRevision cases.
  • I included the rules about the reduced dialog for successive edits to the same article.
  • I added the second link in the dialog for continuing to edit the same article. I made this just say "Edit this article again" instead of "Close and edit this article again" to save space for long languages. I don't think we want that button to end up being two lines.
  • I added the part about displaying the shortened dialog when no suggestions could be found.
  • I specified that on mobile, the link should go to to the suggested edits module, not the homepage.
  • I updated the instrumentation section to account for that new link.

Does this look right to both of you?

@RHo -- I think the first mockup in the task description, showing the desktop dialog, needs to be updated to include the option to continue editing the same article.

Tgr added a comment.Apr 27 2020, 9:23 AM

Thanks @MMiller_WMF!

with taskwithout task
desktop
mobile

Long text:

The two components should animate together up from the bottom of the screen.

The description doesn't say it explicitly but I've assumed this is only for mobile.

it should override any other post-edit toasts or notices.

Note there is no generic way to do this; post-edit actions are done via a hook system, and mw.hook doesn't allow manipulation of existing hooks. We can hack around the core and MobileFrontend notices by changing the respective codebases, but if anything else chooses to add post-edit actions, there's not much to do about that.

Tgr added a comment.Apr 30 2020, 5:00 PM

Per discussion yesterday, 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).

@Tgr -- your notes about animation and overrides sound fine. If we just override the things that exist now, that will be sufficient. Regarding your screenshots, one thing I noticed is that the text of the buttons is supposed to be blue, not black.

MMiller_WMF updated the task description. (Show Details)Apr 30 2020, 6:01 PM
RHo updated the task description. (Show Details)Apr 30 2020, 8:16 PM

[...]
@RHo -- I think the first mockup in the task description, showing the desktop dialog, needs to be updated to include the option to continue editing the same article.

Updated the Desktop mock to also include the "Edit again" call to action.

MMiller_WMF updated the task description. (Show Details)May 1 2020, 12:16 AM

@Tgr -- note that I made some clarifications to the task description about how the preview card between on mobile and desktop. We also added an additional button on the dialog on desktop for parity with mobile.

RHo added a comment.May 1 2020, 5:59 PM

@MMiller_WMF - after posting proposed design for T244930: Newcomer tasks: post-edit nurture for non-suggested edits, I wanted to check whether we should explicitly ask for the suggested edit shown to users in the post-edit dialog in this task to also be in the same topic as the article they just edited?

Change 589714 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Move rest of API code into GrowthTasksApi

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

@RHo -- I thought about this, and I think the existing specifications will handle this use case well, because it will show an article using the user's existing filter settings from the homepage, so whatever their topics and difficulty settings were before they arrived on the article they just finished editing before the dialog.

RHo added a comment.May 6 2020, 12:50 PM

@RHo -- I thought about this, and I think the existing specifications will handle this use case well, because it will show an article using the user's existing filter settings from the homepage, so whatever their topics and difficulty settings were before they arrived on the article they just finished editing before the dialog.

Ah gotcha. I wonder if it's worth building the extra specificity for the recommendation to be from the same topic as the article they just finished editing (if found), so that it can be applied for the later task T244930, where users are not doing a suggested article?

Scenario 1: A newcomer with interests filtered to Physics and Food & drink saves a suggested edit on the "Bagel" article. It would be preferable imho if the post-edit dialog showed as the next suggested edit "Canelé" (article in the same Food & drink topic) instead of "Thermodynamics".
Scenario 2: A user with no topic filters at all (either a newcomer who hasn't selected interests, or someone making an non-SE edit) saves an edit on "Bagel". The same logic would apply and they would also see "Canelé" or some other Food & drink article.

@RHo -- I agree that it would be a bit better for the next recommendations to match the article that was just edited. But knowing what I know about how the topic models are stored, I don't think this would be trivial to add. Maybe we can come back and add it here once we build it for T244930.

Tgr added a comment.May 7 2020, 8:33 AM

@RHo -- I agree that it would be a bit better for the next recommendations to match the article that was just edited. But knowing what I know about how the topic models are stored, I don't think this would be trivial to add. Maybe we can come back and add it here once we build it for T244930.

We pass along the task type as a URL parameter and then via session storage. We could probably do the same with the topic for Scenario 1. Scenario 2 and post-edit nurture would require T243478: Newcomer tasks: fetch ElasticSearch data for search results.

Change 595173 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Instrumentation for the post-edit dialog

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

Change 595225 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Skip default post-edit notice

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

Change 595226 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Allow skipping the post-edit notice

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

Change 596013 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/MobileFrontend@master] Allow replacing the default post-edit notification

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

MMiller_WMF updated the task description. (Show Details)May 13 2020, 5:07 PM

Change 590790 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add post-edit dialog widget

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

The current text is "You've saved an edit". Since 2016, the usual name for this action (when FlaggedRevisions in not the picture) is "Publish" and not "Save" for legal and UX reasons (see T131132). It is quite consistently applied in wikitext editor, Visual editor, Content Translation, Wikibase, etc.

The ideal solution is to be consistent and use the same word that would be used if this edit was done using WikiEditor or VisualEditor, although somewhat strangely they aren't consistent with each other: VisualEditor says "Publish changes" on articles with FlaggedRevisions enabled, while WikiEditor says "Submit changes" 🤷.

The ideal solution is probably to have "Submit" for pages with FlaggedRevisions and "Publish" elsewhere. Having "Publish" everywhere is acceptable, too, as VisualEditor shows. Having "Save", however, is problematic. Before 2016 it was common for such actions, but now it is used for other things, for example, in Content Translation it refers to internal saving of a translation in progress, before it is published.

Change 597527 had a related patch set uploaded (by Amire80; owner: Amire80):
[mediawiki/extensions/GrowthExperiments@master] Change "save" to "publish"

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

Tgr added a comment.May 21 2020, 12:19 PM

In some sense you are still publishing the edit, since it will be visible to anyone, even if it does not show in the default article view. It would be nice if it said something like "submit for review" but that's a bit too long for a button. (I don't think "Submit" tells anything useful to the user.)

In some sense you are still publishing the edit, since it will be visible to anyone, even if it does not show in the default article view. It would be nice if it said something like "submit for review" but that's a bit too long for a button. (I don't think "Submit" tells anything useful to the user.)

So, if I understand correctly, you think that always using simply "publish" is OK?

Tgr added a comment.May 21 2020, 2:37 PM

TBH I don't think it matters too much whether the post-edit notification uses the exact same choice of word is as the editor submit button. The MediaWiki default post-edit notice is "Your edit was saved.", for example.

RHo added a comment.EditedMay 21 2020, 8:41 PM

hi @Amire80 - not sure if Phabricator hid the older history on this task, but the original message proposed did use the word "publish" and we later changed it to "saved" based on feedback on T245790#6067108 that this is more accurate for arwiki which has a validation step and other wikis with FlaggedRevs. The thinking was that "saved" was a better catch-all term.
That said, I agree the ideal solution would be to use "saved" on arwiki and any wiki with Flaggedrevs, and "published" everywhere else, not only for accuracy but imho it is also a more encouraging and motivating message to call out when the edit has been published and is visible immediately. @Tgr - what do you think about this solution?

@Trizek-WMF -- that is a great point! We should want users who experienced FlaggedRevisions to understand what's going on. @Tgr -- what do you recommend here? Do you know if there is precedent for having different sets of messages depending on whether the wiki has FlaggedRevisions?

@Dyolf77_WMF may help there too.

So, in ar.wiki if a newcomer makes an edit in an article, their edit can't be seen unless an Editor validates the modification.
Using this message: Your edit was published, thanks! will not be accurate in this case,
maybe Your edit was saved, thanks! would be fine for all wikis.

For wikis with FlaggedRevision, AND if the newcomer is not an Editor (like Arabic Wikipedia) we can add an additional message to explain the process of validating edits or when they will be seen by all readers with a link to read more about Wikipedia:Pending changes.
For example, in ar.wiki Editors are users who asked for this status and did at least 150 edits AND created their account before 60 days.

Tgr added a comment.May 22 2020, 11:50 AM

Comparing wgStableRevisionId to wgRevisionId seems like an easy and accurate way to tell whether the current version of the page is shown by default or pending review, so we can easily show different messages.

I wonder if the flagrev version should be something that makes it more clear what's going on (like "your edit has been submitted for review").

It would be nice to keep the language in sync with the core and MobileFrontend post-edit notices (which we suppress on Growth wikis). Not sure how the core message would account for FlaggedRevs, though.

Change 592501 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Display post-edit dialog widget

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

Change 595173 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Instrumentation for the post-edit dialog

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

@Tgr @RHo @Amire80 -- I just did some editing and verifying, and I think this is the situation:

  • VE and wikitext2017 editors always give a "Your edit was published." message.
  • Earlier editors always give a "Your edit was saved." message.
  • Whether Flagged Revisions is on has no bearing on the message.

Given that some inconsistencies exist, I think it's probably best to do what we think is best for the newcomer here. And I agree with @Tgr that the difference between "saved" and "published" is probably too subtle to communicate much. I think we should do this (and I'm putting it in the task description):

  • No FlaggedRevisions: "You've published an edit! Thanks and keep going!"
  • FlaggedRevisions: "Your edit is being reviewed! Thanks and keep going!"
MMiller_WMF updated the task description. (Show Details)May 22 2020, 9:50 PM
RHo added a comment.May 23 2020, 6:40 AM

Thanks @Miller_WMF - having different messages for FlaggedRevs sounds good. I do worry slightly that "your edit is being reviewed" may be not so encouraging or clear, esp. without any explanation who is reviewing it and why, hence the preference for the succinct and simple "saved" like on older editors.

RHo added a comment.EditedMay 25 2020, 5:10 PM

Unrelated to the copy change discussion @Tgr - is it possible to refine the animation? At the moment the success notification and suggested next edit dialog slides up and appears together as one block.
Can we instead fade in the success notification first, and then have the suggested next edit dialog slide up afterwards (on mobile it would also push up the success notification)?

Added animation:

Regarding the FlaggedRevisions

@RHo -- I see why briefly telling newcomers that their edit is "being reviewed" instead of "saved" or "published" could raise questions for them. But I think that it is probably wiser for us to err on the side of trying to tell the newcomer what is actually happening with their edit, instead of saving that news for later. I wonder if there is a way to help them understand it in more depth? Could we have a hyperlink in the message for them to find out more or something?

Regarding the animation

Thanks for noticing that, @RHo.

@Tgr -- if making that change is anything more than trivial, we'll file it separately and do it another time so that this task can proceed across the board. Let us know!

Tgr added a comment.May 26 2020, 10:33 PM

@Tgr -- if making that change is anything more than trivial, we'll file it separately and do it another time so that this task can proceed across the board. Let us know!

Maybe there's an easy way to do it that someone more familiar with OOUI can spot - but the way I added the notice was by making it part of the dialog (with a vertical offset), and with that approach the mobile animation would be non-trivial and the desktop one probably not possible.

RHo added a comment.May 27 2020, 5:29 PM

@Tgr -- if making that change is anything more than trivial, we'll file it separately and do it another time so that this task can proceed across the board. Let us know!

Maybe there's an easy way to do it that someone more familiar with OOUI can spot - but the way I added the notice was by making it part of the dialog (with a vertical offset), and with that approach the mobile animation would be non-trivial and the desktop one probably not possible.

Thanks, in that case let me create as a separate task to investigate. Per offline chat, perhaps @Catrope may know some OOUI /CSS animation method to do this based on his recent work on the other transitions for help panel.

@RHo -- I wanted to make sure you saw/thought about my comment above:

Regarding the FlaggedRevisions

@RHo -- I see why briefly telling newcomers that their edit is "being reviewed" instead of "saved" or "published" could raise questions for them. But I think that it is probably wiser for us to err on the side of trying to tell the newcomer what is actually happening with their edit, instead of saving that news for later. I wonder if there is a way to help them understand it in more depth? Could we have a hyperlink in the message for them to find out more or something?

RHo added a comment.May 28 2020, 9:05 PM

@RHo -- I wanted to make sure you saw/thought about my comment above:

Regarding the FlaggedRevisions

@RHo -- I see why briefly telling newcomers that their edit is "being reviewed" instead of "saved" or "published" could raise questions for them. But I think that it is probably wiser for us to err on the side of trying to tell the newcomer what is actually happening with their edit, instead of saving that news for later. I wonder if there is a way to help them understand it in more depth? Could we have a hyperlink in the message for them to find out more or something?

Thanks for the reminder @MMiller_WMF. I still do prefer "saved" since in that scenario, since it seems the newcomer unlikely to get any 'news' later unless their edit was rejected, in which case the "saved" is still true, but it was just not accepted in the end. I guess my point is that the "being reviewed" message and a newcomer learning about the review process (for example, by following a hyperlink to read more about FlaggedRevs) detracts from the point of this dialog, which is to encourage further editing.

Having said that, if we are going with "being reviewed", then I see no harm in adding a link from "reviewed" to open a pithy explanation page of FlaggedRevs in a new tab.

Okay, I think @RHo is right. We should not distract from the core workflow (but we should think about how to educate users about FlaggedRevisions at some point, or at least figure out if they tend to be confused about it). Let's change it back to the original: "saved" for FlaggedRevisions, and "published" otherwise. I'll change the task description now.

MMiller_WMF updated the task description. (Show Details)May 30 2020, 12:54 AM

Change 595226 merged by jenkins-bot:
[mediawiki/core@master] Allow skipping the post-edit notice

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

Change 596013 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Allow replacing the default post-edit notification

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

Change 601792 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Show different postedit notice for FlaggedRevs pages

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

Change 595225 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Skip default post-edit notice

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

Moving into QA although there are some subtasks (notably T254416) that need resolution still.

Change 601792 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Show different postedit notice for FlaggedRevs pages

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

Change 597527 abandoned by Amire80:
Change "save" to "publish"

Reason:
Superseded by I40acc440e7ca9337a9492a4c6c15870888dc84dd
, thanks

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

Etonkovidova added a comment.EditedJun 6 2020, 12:49 AM

Incidentally, should we do the same when there are no more suggested tasks (with the user's current filter settings) / when fetching them fails for some technical reason, or should there be some kind of no-results / error page? Just not showing the block seems like a nice, low-maintenance way of handling that.

Yes, that sounds good! I created a desktop version as well for the same scenario if that helps. All these mocks have been updated in the Zeplin board now too.

Does the above handles the case when there is just one Suggested edit article in user's filter and a user edits that article?

  • a user selects "Math" topic and "Add links between articles" Easy level filter - the result is one article (e.g. "Statistical unit")
  • a user goes to that article, edits and publishes the change
  • the post-edit dialog shows "Statistical unit" article as the next suggestion:

Etonkovidova updated the task description. (Show Details)Jun 8 2020, 8:03 PM
Tgr added a comment.EditedJun 8 2020, 8:11 PM

Does the above handles the case when there is just one Suggested edit article in user's filter and a user edits that article?

We don't exclude the current article from the pool of potential suggestions for the next task. Should we? It seems fairly easy to do.

For Design review

The items marked with
(1)

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.

In my comment above I described a case when the SE was the only one and it was repeatedly suggested again in the post-edit dialog.

(2)

Footer: contains two buttons. On desktop these buttons are black, and on mobile they are blue -- in line with default styling.

It doesn't seem to be the case for mobile:

desktopmobile

The items marked with
Due to the betalabs setup, I did a very limited testing on that:

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.

Does the above handles the case when there is just one Suggested edit article in user's filter and a user edits that article?

We don't exclude the current article from the pool of potential suggestions for the next task. Should we? It seems fairly easy to do.

I think we should do that. Actually I thought that the above illustrates the case when there are no more suggestions, but you brought another point - exclude the article that just was edited from post-edit suggestions - which would include "no more suggestions" case.

@Tgr @Etonkovidova -- I think that's a great point. I filed this task to exclude the article that was just edited: T254834. It's in Ready for Development in correct priority order. It is not a blocker for release, but would be nice to have.

@Tgr @Etonkovidova -- I think that's a great point. I filed this task to exclude the article that was just edited: T254834. It's in Ready for Development in correct priority order. It is not a blocker for release, but would be nice to have.

T254834: Newcomer tasks: exclude article that was just edited from post-edit suggestions verified and this task is updated - is removed from the specs.

RHo updated the task description. (Show Details)Jun 18 2020, 12:31 PM
RHo updated the task description. (Show Details)Jul 22 2020, 1:36 PM
MMiller_WMF closed this task as Resolved.Sep 2 2020, 3:45 AM

Thank you!