hi @MMiller_WMF - some open questions/details to flesh out the task:

• What should be the number of times of times we show the guidance panel to a user before we show the opt-out dialog?
• What duration should we consider as a minimal to set as indicating a user is dismissing the guidance panel without engaging with its contents?
• Do we want to allow users to opt out by type instead of having to opt out of all guidance? For example, I only want to opt out of Copyedit and Add links tasks guidance because I have done enough of those tasks, but I want to still see guidance for Medium and Hard tasks.

Thanks for thinking about this, @RHo. I like that the user can use both the preferences to opt-out and have the popup if they dismiss the panel a lot. I think this brings up this question that we need to decide:

When the user is "opting out", what are they opting out of? Are they turning off the help panel entirely? Telling it not to include any suggested edit guidance, but to just be the normal help panel? Or merely saying that they don't want it to be open by default, but should still include the suggested edit guidance when they do open it?

I think if we know the answer to that, we can figure out the rest of the specifications. Let me know what you think.

In T246015#5913969, @MMiller_WMF wrote:

Thanks for thinking about this, @RHo. I like that the user can use both the preferences to opt-out and have the popup if they dismiss the panel a lot. I think this brings up this question that we need to decide:

When the user is "opting out", what are they opting out of? Are they turning off the help panel entirely? Telling it not to include any suggested edit guidance, but to just be the normal help panel? Or merely saying that they don't want it to be open by default, but should still include the suggested edit guidance when they do open it?

Good questions. When I am talking about opting out in this task, it is only referring to no longer seeing by default the open pop-up on desktop/full screen overlay on mobile. This is because I do not consider the floating guidance/help CTA to be the interrupting thing that users want to dismiss.
However, if there is a greater requirement as part of the project to enable turning off the thing entirely (similar to users being able to turn off the newcomer homepage entirely from Preferences), I would suggest this is only available in the Preferences section and labeled separately as something like the following:

• Minimize Suggested edits guidance
• Turn off help and Suggested edits guidance on articles

@RHo -- okay, great, so the stakes are actually pretty low when the user opts-out. It just means the guidance will be minimized when they arrive, instead of open by default. But they'll still be able to open it up if they want it. So I think we should include a new preference that the user can get to from the cog in the upper right (like you said).

And then I agree that it's important to apply some kind of timer to whether we prompt users about their preference after they close the panel. How about the rule is:

If the user has completed at least one suggested edit AND...

• Desktop: clicks the "X" on the panel less than three seconds after it pops up in either read or edit mode.
• Mobile: dismisses the mobile peek by tapping outside of it less than three seconds after it pops up in read mode.

Also, the interaction itself -- I don't think we should ask the user "are you sure you want to close the panel?" because the consequences are low. They can just open it again. But I do like the little popup. How about when the user clicks to close, it just closes, and the popup only has the option to not open the panel by default in the future, instead of also having the "Cancel" or "OK" buttons?

And how would we do that interaction on mobile?

I'm thinking while typing so I may be confusing/out of scope.)

I agree we should let the user to define the default state of the guidance panel, like it is done with the help panel. We store somewhere the last status of the guidance panel (displayed/collapsed). If there is something new on a collapsed guidance panel, we could have a short animation to say "hey, there is something you should look at there".

The state of the guidance panel should be reset on a new task, because the guidance is different for the new task. If also should be explicit, by writing in guidance that it is a new task, as a nice CTA: "Great, you are trying a new task! Please find some new advice for you below."

Since the guidance overlaps with the page contents, users are more likely to immediately close the guidance to check the article's contents. This is something we need to take into account if we monitor how fast they press the X button.

To avoid the confirmation pop-up being displayed every time they press the X button, some users may decide to dismiss the guidance for good. We would loose them because because of interaction, not because they don't need guidance.

Re-activating guidance in Preferences is unlikely to happen, given the fact that it is a maze and even experiences users are getting lost there.

Thanks for the comments, @Trizek-WMF. I agree with some and not with others.

Right now, we are not saving any state of the help panel. Every time a user loads the editor, the panel starts out as closed, even if they had it open last time the editor was open.

I like your point about the confirmation pop-up. If the user fits the criteria to get the pop-up asking if they want to stop the panel from opening by default, but they don't tell it to stop, should we also give them the pop-up if they dismiss quickly the next time they open a suggested edit. I think we should only give the user this option once -- the first time they fit the criteria for the pop-up (i.e. have a completed suggested edit and close within 3 seconds).

@RHo -- what do you think of my previous comment, and this comment?

In T246015#5925018, @MMiller_WMF wrote:

Thanks for the comments, @Trizek-WMF. I agree with some and not with others.

Right now, we are not saving any state of the help panel. Every time a user loads the editor, the panel starts out as closed, even if they had it open last time the editor was open.

I like your point about the confirmation pop-up. If the user fits the criteria to get the pop-up asking if they want to stop the panel from opening by default, but they don't tell it to stop, should we also give them the pop-up if they dismiss quickly the next time they open a suggested edit. I think we should only give the user this option once -- the first time they fit the criteria for the pop-up (i.e. have a completed suggested edit and close within 3 seconds).

@RHo -- what do you think of my previous comment, and this comment?

Hi @MMiller_WMF - I think we are in agreement. To recap, this is what I've captured in the updated desktop and new mobile mocks:

• The Opt-out prompt we will offer here is actually to minimize/close the panel by default, not to disable the tool completely.
• Part 1's is about offering users the option to go to Preferences to disable the tool completely from there (a feature that is currently available for help panel), as well as a new less aggressive preference about it to minimize/close the guidance panel by default
• Part 2's opt out dialog will appear if a user who has finished at least 1 suggested edit, takes the action to close/dismiss the guidance panel/peek within 3 seconds.
• The dialog asks if the user wants to keep the panel minimized by default with a Yes/No option, but now they do not have to check a checkbox as this is the only choice.

Re-tagging this open task with GrowthExperiments-NewcomerTasks as NewcomerTasks 1.2 recently got archived and as tasks ideally have a code project tag.