i.e. if the user has not interacted with the panel in read mode, the tips should still be auto-advancing when the user gets to edit mode.

@MMiller_WMF @RHo does this mean that the tips should keep advancing in the background (e.g. after tip set 6, it cycles back to tip set 1) ?

In T253009#6144541, @kostajh wrote:

i.e. if the user has not interacted with the panel in read mode, the tips should still be auto-advancing when the user gets to edit mode.

@MMiller_WMF @RHo does this mean that the tips should keep advancing in the background (e.g. after tip set 6, it cycles back to tip set 1) ?

Yes please.

@kostajh -- I think it would be best if we don't log any events for auto-advancing. Would that work? I think we're only going to want to know when the user affirmatively advances the tips, not when it happens automatically. Are we going to be separately logging impressions of the tips and advances of the tips?

In T253009#6154449, @MMiller_WMF wrote:

@kostajh -- I think it would be best if we don't log any events for auto-advancing. Would that work? I think we're only going to want to know when the user affirmatively advances the tips, not when it happens automatically. Are we going to be separately logging impressions of the tips and advances of the tips?

OK not logging auto advancing makes sense. I need to think about the logging impressions of tips and advances of the tips.

Change 604177 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Auto-advance suggested edits guidance tabs

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

If the user navigates from Edit *back* to another mode (eg., Edit Source or Read mode) or else refreshes the page from Edit in the same session, this 'counts' as an interaction that stops the auto-advancing action.

The behavior of the current patch does not follow this, because auto-advance relies on the rules from T244431: Newcomer tasks: guidance panel behavior for what counts as an interaction, and those rules are slightly different (or maybe just interpreted slighlty differently). I hope we can avoid having two different "interacted" flags, it adds mental and code complexity.

In T253009#6213068, @Tgr wrote:

If the user navigates from Edit *back* to another mode (eg., Edit Source or Read mode) or else refreshes the page from Edit in the same session, this 'counts' as an interaction that stops the auto-advancing action.

The behavior of the current patch does not follow this, because auto-advance relies on the rules from T244431: Newcomer tasks: guidance panel behavior for what counts as an interaction, and those rules are slightly different (or maybe just interpreted slighlty differently). I hope we can avoid having two different "interacted" flags, it adds mental and code complexity.

Ah I may have misinterpreted the rules from T24431 that refreshing or 'completing' and edit counts as an interaction. So does that mean in the above scenario (user goes back from Edit to Read mode without touching the default opened guidance panel) the tips should continue to auto-advance? I think that would be fine.

So does that mean in the above scenario (user goes back from Edit to Read mode without touching the default opened guidance panel) the tips should continue to auto-advance? I think that would be fine.

That scenario is not reachable from the business rules we landed on with T244431: Newcomer tasks: guidance panel behavior. If the user clicks on "Edit" without clicking on any of the tips, we take them to the root screen. Then on the root screen, if they click the button to go back to the guidance panel, the patch disables the auto advancing of the tips. Should we not disable auto advancing in that scenario?

In T253009#6218509, @kostajh wrote:

So does that mean in the above scenario (user goes back from Edit to Read mode without touching the default opened guidance panel) the tips should continue to auto-advance? I think that would be fine.

That scenario is not reachable from the business rules we landed on with T244431: Newcomer tasks: guidance panel behavior. If the user clicks on "Edit" without clicking on any of the tips, we take them to the root screen. Then on the root screen, if they click the button to go back to the guidance panel, the patch disables the auto advancing of the tips. Should we not disable auto advancing in that scenario?

Ah I see. Yes, it would be preferable that the tips continue to auto advance in this scenario.

Change 604177 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Auto-advance suggested edits guidance tabs

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

Change 605953 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Fix guidance auto-advance when there's no guidance

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

Change 605953 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Fix guidance auto-advance when there's no guidance

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

@kostajh @Tgr -- in light of today's retro conversation, I have updated the task description with the specifications we changed via this task's comments. But also in light of today's retro conversation, I want to go back over a couple things. With respect to @Tgr's comment about having multiple definitions of interaction (T253009#6213068), where did we land on that? I would be happy to work this out so there is just one definition. And similarly, with this discussion about returning to the suggested edit screen from the root screen (T253009#6218589), it sounds like we may have added another idiosyncrasy to our code that we could simplify. I would be fine with not continuing to auto-advance in that scenario, if that simplifies out code.

@RHo, @MMiller_WMF - please review the current implementation.
Going over the specs and adding notes after testing:
(1)

The tips auto-advance every five seconds until the user has interacted with the panel in some way.

Done
(2)

Once the user interacts with the panel, the tips stay on whichever one they were on when the user interacted.

Done

(3) - once a user clicks on Edit - the advancing stops; there is no way to bring it back. The following specs are not Done

This specification extends across the reading and editing experiences, i.e. if the user has not interacted with the panel in read mode, the tips should still be auto-advancing when the user gets to edit mode.

and

If the user navigates from Edit *back* to another mode (eg., Edit Source or Read mode) still without interacting with the tips, they should continue to auto-advance.

As far as I understood the specs in this comment, the desired behavior is the following:

• a user sees SE guidance panel with advancing tips
• does not interact with the guidance panel and clicks on Edit
• sees the root screen (the guidance panel is closed)
• if a user opens now the guidance panel -the tips should be advancing from the tip which was at the moment when a user clicked on Edit

The tips advancing stops at the tip that was displayed in Read mode when a user clicked Edit and not advancing anymore.

(4) Btw, is it intentional that the guidance/help panel is displayed on View history?

Thanks @Etonkovidova - my comments inline below before @MMiller_WMF does his review:

In T253009#6233550, @Etonkovidova wrote:

(3) - once a user clicks on Edit - the advancing stops; there is no way to bring it back. The following specs are not Done

This specification extends across the reading and editing experiences, i.e. if the user has not interacted with the panel in read mode, the tips should still be auto-advancing when the user gets to edit mode.

and

If the user navigates from Edit *back* to another mode (eg., Edit Source or Read mode) still without interacting with the tips, they should continue to auto-advance.

As far as I understood the specs in this comment, the desired behavior is the following:

• a user sees SE guidance panel with advancing tips
• does not interact with the guidance panel and clicks on Edit
• sees the root screen (the guidance panel is closed)
• if a user opens now the guidance panel -the tips should be advancing from the tip which was at the moment when a user clicked on Edit

The tips advancing stops at the tip that was displayed in Read mode when a user clicked Edit and not advancing anymore.

I think we are OK with it not advancing anymore for the purposes of code simplicity as mentioned in the comment below:

In T253009#6229664, @MMiller_WMF wrote:

[...] And similarly, with this discussion about returning to the suggested edit screen from the root screen (T253009#6218589), it sounds like we may have added another idiosyncrasy to our code that we could simplify. I would be fine with not continuing to auto-advance in that scenario, if that simplifies out code.

(4) Btw, is it intentional that the guidance/help panel is displayed on View history?

Since we are showing the guidance+help panel in Read and Edit mode on suggested edit articles, I think it makes sense to keep showing it on View history too, as it can help redirect users if they accidentally click on View history.

I'll get back to the issue of when to stop auto-advance after T244431: Newcomer tasks: guidance panel behavior lands, since they share rules.

is it intentional that the guidance/help panel is displayed on View history?

The current logic is to keep showing the panel as long as the user is in the suggested edit session - that is, started from a task card and than has not navigated away from that title. So anything related to that title (view, edit, history, page information, even the page protection and deletion form in the unlikely case the user has permissions for it) will show the panel. It's not intentional; we can restrict it to specific actions if we want.

Thanks, @RHo and @Tgr - all comments make perfect sense.

To summarize - currently, tips advancing is present only when a user lands on SE article from Homepage SE or when a user opens a SE article from the post-edit dialog box.

Change 607330 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Align auto-advance rules with interaction flag

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

Change 607330 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Align auto-advance rules with interaction flag

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

In T253009#6229664, @MMiller_WMF wrote:

With respect to @Tgr's comment about having multiple definitions of interaction (T253009#6213068), where did we land on that? I would be happy to work this out so there is just one definition.

The current rules are:

• Both auto-advance and the suggested-edits -> home auto-switch only happen when there has not been any interaction in the current suggested edit session.
• Suggested edit sessions start when the user clicks on a task card and last as long as the user is on the same title.
• The following are treated as user interaction:
  • Clicking on a tab (tip number) in suggested edits guidance
  • Navigating from guidance to the root screen
  • Editing the article

As @Etonkovidova pointed out, this doesn't match the task description, according to which, after editing the article and then saving/cancelling, there should still be auto-advance. (Which is easily doable, but we should try to end up with a set of rules which are easy to describe and remember, IMO.)

@Tgr -- the rules you wrote down here sound good to me for all situations in which we need definitions of "interaction". The only thing I would like to clarify is what we mean by "editing the article". I think we mean "saves an edit". Is that right? If so, then yes, let's use this definition for all purposes.

In T253009#6255214, @MMiller_WMF wrote:

The only thing I would like to clarify is what we mean by "editing the article". I think we mean "saves an edit".

No, opening an article for editing (or more precisely, any displaying of the help panel while the article is open for editing) counts as an interaction now.

@Tgr -- okay that's fine. Let's use that definition for everything.

In T253009#6254148, @Tgr wrote:

• The following are treated as user interaction:
  • Clicking on a tab (tip number) in suggested edits guidance
  • Navigating from guidance to the root screen
  • Editing the article

When testing T255850, I noticed that "user interaction" might include vertically scrolling the content in the guidance panel. Trying to read the content and, thus, scrolling down, and having the tips keep advancing might be felt as unexpected by users.
Right now it's not often when users need to scroll down to be able to read the content, but it might be a more common case in the future.
Note: As an opinion - it'd seem logical if the auto advancing would stop after a user clicks anywhere in the guidance panel (not directly on the tips numbers).

In T253009#6260727, @Etonkovidova wrote:

Note: As an opinion - it'd seem logical if the auto advancing would stop after a user clicks anywhere in the guidance panel (not directly on the tips numbers).

Treating clicking or scrolling (which can happen without clicking, on desktop) as an interaction sounds reasonable. @MMiller_WMF what do you think?

(for the time being I'm moving this to the QA column as I don't think there is anything to fix or review here.)

@Tgr @Etonkovidova -- thanks for bringing that up. I agree it sounds reasonable, but I think the difference will be subtle enough that we should skip it and just continue with what we already have.

For Design Review

• my previous comment summarizes the current behavior:

To summarize - currently, tips advancing is present only when a user lands on SE article from Homepage SE or when a user opens a SE article from the post-edit dialog box.

• I agree with the following:

In T253009#6266440, @MMiller_WMF wrote:

@Tgr @Etonkovidova -- thanks for bringing that up. I agree it sounds reasonable, but I think the difference will be subtle enough that we should skip it and just continue with what we already have.

Right - the behavior is reasonable enough. The original spec about auto-advancing after a user switches to Edit etc - doesn't add too much to users' experience.
On the other hand, scrolling (and clicking in the guidance panel) might be considered as a user interaction that stops auto-advancing.

I also agree the behaviour right now is reasonable enough to move along.