Hi @MMiller_WMF @RHo — I wanted to clarify a use case that could end up being rather complicated to support.

1. Start image suggestions task
2. Skip
3. Next task is loaded, start task
4. Click back (via browser button)

With the current setup, the user will see the article from step 1 in edit mode (based on the URL when they left), but without the structured task since the corresponding session for the task has ended. Do we have to show the structured task flow again in this case?

If that's the case, we might have to rework how a session is determined (or consider an article in additional to the homepage as an entry point for structured task). @kostajh @Tgr please correct me if I'm wrong—my understanding is that this will be a new use case where we go from one in-progress task to another (the closest would be the post-edit dialog, but in that case, the session has ended so we don't need to figure out whether to re-start the session).

In the case of the post-edit dialog we use a fresh search result so we know it will be a valid task. When going back to a previous task page, we don't know whether we got here via skip or the user accepting/rejecting (in which case there's no task anymore). Seems to me like a big effort with questionable benefits to try to handle back-navigation in any useful way.

In T290910#7360654, @mewoph wrote:

Hi @MMiller_WMF @RHo — I wanted to clarify a use case that could end up being rather complicated to support.

1. Start image suggestions task
2. Skip
3. Next task is loaded, start task
4. Click back (via browser button)

With the current setup, the user will see the article from step 1 in edit mode (based on the URL when they left), but without the structured task since the corresponding session for the task has ended. Do we have to show the structured task flow again in this case?

If that's the case, we might have to rework how a session is determined (or consider an article in additional to the homepage as an entry point for structured task). @kostajh @Tgr please correct me if I'm wrong—my understanding is that this will be a new use case where we go from one in-progress task to another (the closest would be the post-edit dialog, but in that case, the session has ended so we don't need to figure out whether to re-start the session).

Hi @mewoph - actually we would NOT want to skip directly to the next task. We would actually want to have a similar workflow to as if the user had skipped all links in the add links task whereby they are returned to the suggested edits feed to select the next task.
One thing that is still TBD is that we may instead rename this to be "Not sure" and potentially bring up a set of "Not sure" reasons every Nth time someone presses this button.

Thanks for confirming @RHo — moving this back to Incoming w/placeholder keyword

@RHo -- I'd like to clarify our specifications here. You wrote that when the user taps "Not sure", they should be taken back to their suggested edits feed, with a dialog in between asking them to confirm. This is different than what we do for links: if the user skips all the links and confirms so in the dialog, they are taken to the post-edit dialog state that looks like this (see T269658 for the original specifications for "add a link"):

I think we should do the same behavior for both tasks. Which do you prefer? I think we should align to the links behavior, so if a user skips the image, they get to the post-edit dialog to get another suggestion.

In T290910#7395989, @MMiller_WMF wrote:

@RHo -- I'd like to clarify our specifications here. You wrote that when the user taps "Not sure", they should be taken back to their suggested edits feed, with a dialog in between asking them to confirm. This is different than what we do for links: if the user skips all the links and confirms so in the dialog, they are taken to the post-edit dialog state that looks like this (see T269658 for the original specifications for "add a link"):

I think we should do the same behavior for both tasks. Which do you prefer? I think we should align to the links behavior, so if a user skips the image, they get to the post-edit dialog to get another suggestion.

Hi @MMiller_WMF - sure, we can have them go to the (no changes version) post-edit dialog after confirming the image skip. My minor concern is that showing a confirmation to say "are you sure you're not sure" seems like we want to force a decision, which is not so much thte case with image suggestions. However, this is something that can be addressed in the copy since ultimately it's better to have the confirmation in case it is an accidental tap. I've updated the Figma spec and this task description.

Hi @RHo I was looking at the existing skipped all dialog for add link. It looks like we are using the default styling from OOUI MessageDialog which is different from the specs in Figma. Can you confirm whether we should be customizing the dialog styles or if we should stick to the default (for both add link & add image tasks)?

In T290910#7420693, @mewoph wrote:

Hi @RHo I was looking at the existing skipped all dialog for add link. It looks like we are using the default styling from OOUI MessageDialog which is different from the specs in Figma. Can you confirm whether we should be customizing the dialog styles or if we should stick to the default (for both add link & add image tasks)?

Ahhh thanks for noticing @mewoph. In the interest of not increasing scope for v1 let's use the default MessageDialog styles. As an aside, is there a bug in the OOUI dialog though? Your screenshot shows the Skip all button as being wider than the "Review again" action when the expectation would be that they should be equal width.

Change 730313 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add an image: Skip funtionality

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

Updated skip all dialogs for add link & add image (Note to @Etonkovidova — the change for this required some refactoring of add link's skip all logic so it would be good to check add link as well, thanks!)

Add link:

Add image;

Change 730313 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add an image: Skip funtionality

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

@RHo (cc @mewoph) - the post-edit dialog in betalabs looks different from what presented in https://phabricator.wikimedia.org/T290910#7421358.

mockup Confirmation dialog	betalabs Confirmation dialog

mockup Post-edit dialog	betalabs Post-edit dialog
	"Add an image" vs "Add a suggested image"? copy spreadsheet doesn't have the message

Thanks @Etonkovidova - I think this is OK to resolve assuming that the style issues will be taken care of as part of the post-edit dialog task T290789, unless you prefer to keep open to track that the string you mentioned in item [2] is updated - comments below.

In T290910#7491233, @Etonkovidova wrote:

@RHo (cc @mewoph) - the post-edit dialog in betalabs looks different from what presented in https://phabricator.wikimedia.org/T290910#7421358.

mockup Confirmation dialog	betalabs Confirmation dialog

I think this is fine as the button changes from side-by-side to stacked when the string is longer than the dialog width allows for this component.

mockup Post-edit dialog	betalabs Post-edit dialog
	"Add an image" vs "Add a suggested image"? copy spreadsheet doesn't have the message

The reason it isn't in the spreadsheet is I think it technically "belongs" to the mini-card that is part of the Suggested edits module preview which has not yet been updated with the revised name Add a suggested image. @mewoph - is that right, and is there a need to file a separate task to get this string updated or will it come with the copy updates to the SE module T289827?

Hi @RHo that's correct. The copy hasn't been updated yet.

Style and copy issues are fine afaict

Skip dialog on cswiki

Post-edit dialog