Page MenuHomePhabricator

Newcomer tasks: guidance panel behavior
Closed, ResolvedPublic

Description

This task describes the overarching framework for the entire guidance user experience, in terms of which components appear under which conditions, and how they transition. It links to the many sub-tasks that describe the components in detail.

The specifications here follow along with the corresponding prototypes. Where they differ, the written specifications take precedent:

NOTE: For redlined design specs see the Growth Zeplin board for the relevant screens tagged "Guidance v1.2"

When the guidance experience occurs

The guidance experience described below should occur after a user arrives on a suggested edit, whether from 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.

We should also change the help panel at all other times it is shown (i.e. outside of the suggested edits flow). It should look like the guidance edition, but without the "Suggested edit" box at the top. Otherwise functionally it works the same as the new help panel (tree structure navigation, new animation effects, etc).

Experience upon arrival

After clicking edit

  • Desktop
    • On single-tab editor wikis, users who click edit from the newcomer tasks workflow should have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings. We are doing this because we believe the visual editor will be a better experience for newcomers, and that they will be more likely to succeed in their first edits. Likewise, our guidance content (T245786) is written geared toward the visual editor. But we should only send the user into visual editor the first time they open a suggested edit. If they visit a suggested edit task, and subsequently change over to the wikitext editor, on their next suggested edit, their preferred editor should open.
    • After the user clicks edit and the editor loads, the panel should remain in the state it was in before the user clicked edit. i.e. if it was open to Quick Start tip #4, it should still be open to Quick Start tip #4. If it was minimized, it should remain minimized.
    • If the panel was open before the user clicked edit, the panel should not animate up from the bottom of the page again. It should just keep looking like it looked before.
  • Mobile
    • Users who click the edit pencil should have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings. We are doing this because we believe the visual editor will be a better experience for newcomers, and that they will be more likely to succeed in their first edits. Likewise, our guidance content (T245786) is written geared toward the visual editor. But we should only send the user into visual editor the first time they open a suggested edit. If they visit a suggested edit task, and subsequently change over to the wikitext editor, on their next suggested edit, their preferred editor should open.
    • After the user clicks edit and the editor loads, the panel should be minimized.
    • When the user opens it back up, the panel should remain in the state it was in before the user clicked edit. i.e. if it was open to Quick Start tip #4, it should still be open to Quick Start tip #4.
  • The "root screen" will have three buttons. When the user clicks them, the panel should swipe animate to the selected content (a "branch").
  • When on a "branch", the panel should display a "Back" button in the lower left, that causes the panel to swipe animate back to the "root content".

After saving an edit

Instrumentation

  • Add info in action_data when user switches to edit mode from read (and help panel switches modes)
  • Add action_data for when help panel auto opens

Related Objects

StatusSubtypeAssignedTask
Resolved Rileych
Resolvedkostajh
ResolvedCatrope
Resolvedkostajh
Resolvedkostajh
Resolvedkostajh
ResolvedBUG REPORTkostajh
Resolvedkostajh
ResolvedMMiller_WMF
ResolvedCatrope
Resolvedkostajh
ResolvedTgr
ResolvedTgr
OpenNone
Resolvedkostajh
DuplicateNone
ResolvedCatrope
ResolvedTgr
ResolvedBUG REPORTTgr
ResolvedTgr
Resolvedkostajh
ResolvedTgr
ResolvedBUG REPORTCatrope
OpenNone
Resolvedkostajh
ResolvedCatrope
Resolvedkostajh
Resolvedkostajh
ResolvedBUG REPORTkostajh
ResolvedTgr
InvalidRHo
ResolvedTgr
ResolvedTgr
Resolvedkostajh
InvalidNone
ResolvedTgr
Resolvedkostajh
ResolvedTgr
InvalidNone
ResolvedTgr
Resolvedkostajh
ResolvedTgr
ResolvedTgr
DeclinedNone
Resolvedkostajh
Resolvedkostajh
ResolvedBUG REPORTTgr
ResolvedTgr
ResolvedCatrope
Resolvedkostajh
ResolvedBUG REPORTCatrope

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 599787 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help panel: Don't swap panels when switching to edit mode

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

Thanks @MMiller_WMF. Some follow-up questions:

  1. user arrives on an article and guidance appears in the "fixed" mode (there is just an X, you can't navigate back to the root screen)
  2. user clicks "Edit", should the help panel guidance remain in "fixed" mode or should they now also be able to navigate back to the root screen via the top left button?

Related scenario:

  1. user arrives on an article and guidance appears in the "fixed" mode (there is just an X, you can't navigate back to the root screen)
  2. user clicks the "X" to close the help panel
  3. user clicks "Edit", help panel is still minimized
  4. user clicks to open the help panel, should they see a) the guidance screen in "fixed mode" with no ability to navigate back, b) the guidance screen in regular mode, so they can navigate back, or c) the root screen (since they closed the help panel, this might make sense)

@kostajh -- for the first scenario, you've got it exactly right. The user gets to the article in read mode, they see the suggested edits guidance, and they can't navigate to the root screen. Then they click edit, and they still see the same suggested edits guidance, but they can navigate to the root screen.

In the second scenario, the user should see (b) the guidance screen in regular mode. The governing concept is that closing the panel does not affect what it contains when its open. The panels open/closed status and its content are independent.

Presently, the two links in the three-dot menu seem a little bit out of context of the guidance panel.

Screen Shot 2020-06-01 at 8.57.56 PM.png (485×524 px, 52 KB)

  • "Disable this tool in Preferences" redirects to Special:Preferences#mw-prefsection-editing . The title of the panel is "Suggested edits" and in the Read mode users will not have a knowledge that it's, in fact, Help panel and the option "Enable the editor help panel" needs to be disabled to get rid of the panel.
  • "More about this feature" redirects to Growth/Focus on help desk/Help panel where the guidance panel is not mentioned.

Thanks for thinking about that, @Etonkovidova. For the disabling of the tool, I am not too worried about that one -- I think many users will make the connection, and we also know that that option is used rarely.

For the help page, I think this is something @Trizek-WMF can help with. @Trizek-WMF -- could you include a prominent link on the help panel page on mediawiki.org that explains that the user will also encounter the panel while doing suggested edits, and then link to the suggested edits help page?

Change 602050 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help panel: Update guidance behavior rules

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

Change 599787 abandoned by Kosta Harlan:
Help panel: Don't swap panels when switching to edit mode

Reason:
superseded by I39fa8fc84b4be6441333a740a62fbd56c34d75df

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

The title of the panel is "Suggested edits" and in the Read mode users will not have a knowledge that it's, in fact, Help panel and the option "Enable the editor help panel" needs to be disabled to get rid of the panel.

Maybe we could revisit T34811: Direct link to a setting in Special:Preferences.

@kostajh -- for the first scenario, you've got it exactly right. The user gets to the article in read mode, they see the suggested edits guidance, and they can't navigate to the root screen. Then they click edit, and they still see the same suggested edits guidance, but they can navigate to the root screen.

In the second scenario, the user should see (b) the guidance screen in regular mode. The governing concept is that closing the panel does not affect what it contains when its open. The panels open/closed status and its content are independent.

And to follow up with one more scenario:

  1. user sees guidance in "fixed" mode
  2. user clicks edit, panel switches to "edit" mode where they can go back to root screen
  3. user clicks "read"

In step 3, does the panel stay in "edit" mode or does it go back to fixed mode?

@RHo @MMiller_WMF I think we discussed this before but I wonder if we could consider removing the concept of the fixed/non-fixed statuses to the help panel (i.e. you'd always be able to go back to the root screen), because it adds complexity to the code and IMHO not a ton of benefit to the end user experience. But I'll keep working under the assumption that we want to keep this concept.

@MMiller_WMF what I've implemented in the patch for review:

  • After the first impression of the help panel in guidance mode, it should be unlocked
  • If the user switches to edit mode with the panel open, they should now see the unlocked help panel where they can get to the root screen
  • If the user closes the help panel then clicks edit, they should see the unlocked help panel where they can get to the root screen
  • If the user closes the help panel, we should remember that it's closed when switching to VE or wikitext editor
  • If the user is on the ask-help or general-help subpanels, and switches editor tabs, the help panel should stay open (or re-open in case of page reload) to where they were
  • Switching to Read from Edit / Edit source should preserve the help panel state

Sounds good?

@kostajh -- thank you for proceeding with your plans even though you didn't hear from me yesterday. It has taken @RHo and me a little while to sort this. We now think the following:

  1. We can do away with the locked/unlocked concept. The entire help panel, including the root screen, can be present in both read and edit mode. But note that the suggested edits screen should only be available when the user is doing a suggested edit.
  2. When the user arrives in read mode, they should see the panel with the suggested edits screen and the back arrow to go to the root screen.
  3. If the user clicks "Edit" without having navigated any of the tips while they were in read mode, then the panel should animate to the root screen.
  4. If the user clicked "Edit" after having navigated any of the tips while the were in read mode, then the panel should stay showing the same content it was before (except the "click edit" footer should go away).
  5. From that point on, as they continue to click between read and edit mode on that article, the panel should keep showing whatever it was showing before they toggled.
  6. The open/close state should remain independent of their mode or where they are in the screens. If it's open/closed, it should stay open/closed until they close/open it.
  7. The next time the user is doing a suggested edit, everything is forgotten, and this starts over from the beginning.

How is that? Do points #3 and #4 introduce problems?

Thanks for the clarifications; I have a patch up for points 1-2 and 5-7.

If the user clicks "Edit" without having navigated any of the tips while they were in read mode, then the panel should animate to the root screen.
If the user clicked "Edit" after having navigated any of the tips while the were in read mode, then the panel should stay showing the same content it was before (except the "click edit" footer should go away).
How is that? Do points #3 and #4 introduce problems?

We can implement 3 and 4 (I'll push a patch for this shortly) but it does add some more complexity to the code, and IMO from a user perspective it feels unexpected to see the help panel animate to the home screen at the same time that VE is sliding into place. Do you want to prioritize those two business rule changes above the other stuff in ready for development?

If the user clicks "Edit" without having navigated any of the tips while they were in read mode, then the panel should animate to the root screen.

What should we do if the user is on Read, doesn't interact with the tips, clicks on "Ask the help desk", then presses "Edit"? Should we animate back to the home screen or leave them on the ask help desk screen?

On single-tab editor wikis, users who click edit from the newcomer tasks workflow should have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings. We are doing this because we believe the visual editor will be a better experience for newcomers, and that they will be more likely to succeed in their first edits. Likewise, our guidance content (T245786) is written geared toward the visual editor. But we should only send the user into visual editor the first time they open a suggested edit. If they visit a suggested edit task, and subsequently change over to the wikitext editor, on their next suggested edit, their preferred editor should open.

I don't think we've implemented this yet. We will need a patch for this.

After the user clicks edit and the editor loads, the panel should remain in the state it was in before the user clicked edit. i.e. if it was open to Quick Start tip #4, it should still be open to Quick Start tip #4. If it was minimized, it should remain minimized.

Currently we track the panel but not the open tip that was open, this needs a patch. I'll see if I can add it to my current one which is tracking help panel state.

All popups, notices, and Guided Tours should be suppressed (see T235566: Newcomer tasks: suppress editor popups for guidance).

We've done the work on this for VE, but looking at the patches merged on T235566, it seems like we still need to do work for GuidedTours and Getting Started.

Change 603455 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] DNM: Help panel: track tab interactions in state

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

Change 603462 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help panel tips: Store current tip tab in state

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

Currently we track the panel but not the open tip that was open, this needs a patch. I'll see if I can add it to my current one which is tracking help panel state.

Done in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GrowthExperiments/+/603462

Silently overriding the user's tab preferences seems like a very confusing user experience. Could we maybe show a popup suggesting them to switch, instead?

Change 603547 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help panel: Show help panel in read mode if there is an active session

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

@kostajh @Tgr @Catrope @RHo -- I'm putting all our decisions from today's meeting here in this comment, as well as addressing the above comments from today on the task.

We can implement 3 and 4 (I'll push a patch for this shortly) but it does add some more complexity to the code, and IMO from a user perspective it feels unexpected to see the help panel animate to the home screen at the same time that VE is sliding into place. Do you want to prioritize those two business rule changes above the other stuff in ready for development?

We decided that we do want to stick with this behavior. We do not consider this behavior to be more important than our blockers. If we're not able to get it in this week, then we want to use this simple behavior: the panel's state should not be changed by switching between reading and editing mode or back again. Wherever the user has left it, that's where it should stay.

What should we do if the user is on Read, doesn't interact with the tips, clicks on "Ask the help desk", then presses "Edit"? Should we animate back to the home screen or leave them on the ask help desk screen?

This edge case made us realize that our rule can be summarized as: if the user in read mode changes the state of panel, by toggling tips or navigating which screen they're on, then switching modes should not change the state of the panel. It's only if the have not touched the help panel in read mode that we would want it to animate back to the root screen upon switching to edit mode. (And at that point, if the user toggles back to edit mode without touching the panel, no more changing happens -- it would stay at the root screen).

We've done the work on this for VE, but looking at the patches merged on T235566, it seems like we still need to do work for GuidedTours and Getting Started.

We decided that suppressing VE popups is sufficient here, since the wikis we're working with don't have GettingStarted. We'll revisit the GettingStarted situation later, or address it if we see it interrupting the flow as we test in production.

Silently overriding the user's tab preferences seems like a very confusing user experience. Could we maybe show a popup suggesting them to switch, instead?

We decided not to implement this for now. If a user is on a single-tab wiki and they somehow have wikitext as their default, the wikitext editor will open up. We think this will affect a small number of users because all the single-tab wikis we work in open VE by default. This decision has been broken out into this separate task: T254823: Newcomer tasks: switch to visual editor (mobile)

We can do away with the locked/unlocked concept. The entire help panel, including the root screen, can be present in both read and edit mode. But note that the suggested edits screen should only be available when the user is doing a suggested edit.

One thing I just realized about this; on mobile, this requires two taps from the user since there is no longer an X button when they see guidance; they'll have to know to click the back arrow and then the X before they see the edit pencil. Is that OK or do we want to reconsider locked/unlocked?

Change 603462 abandoned by Kosta Harlan:
Help panel tips: Store current tip tab in state

Reason:
Included in I39fa8fc84b4be6441333a740a62fbd56c34d75df

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

Change 603547 abandoned by Kosta Harlan:
Help panel: Show help panel in read mode if there is an active session

Reason:
Included in I39fa8fc84b4be6441333a740a62fbd56c34d75df

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

Change 602050 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help panel: Update guidance behavior rules

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

Note from @Tgr in private chat that I wanted to make sure was captured here:

We'll probably need to rethink our logging, e.g. an open event is logged when the panel is auto-opened to resume its previous state
We have a number of things where filtering for human actions was not needed before but probably is now

@nettrom_WMF, how would you like us to deal with this in the instrumentation? For things like auto-advancing tips, we probably just shouldn't log anything at all, but what about panel open events that are really resumptions?

@Catrope and @Tgr : thanks for identifying this issue! I went and looked at the measurement plan, and from what I can tell we don't have a specific need for tracking the recreation of state after the user clicks "Edit". Therefore I think it becomes a question of how many events we should log in order to make it easy to understand what a user did if we're looking at data, and to enable us to identify issues if we have them.

I think the only events I really care about are the impression and open actions, as they make it easy to identify when the edit context interactions would start. If the user had the Guidance screen open and then clicks "Edit", will we log both an impression and an open event, or would it just be the latter? If there isn't actually an impression it makes sense to me that we'd only log the open event. And perhaps we can add something to action_data to flag it as a system event, rather than a human-initiated event?

I agree that it makes sense to not log things like auto-advancing that are done to recreate state.

@kostajh (cc @Tgr @Catrope @Etonkovidova) -- I just went through and tested on beta, and I think that new patch mostly puts us in a good place! Thank you for working on it. At this point, we have been tweaking the business rules in so many places (Phab, email, Slack) that we no longer have a canonical set of rules to test against. Do you think you could write down in bullet points what we should expect to see in the interface post-patch?

But based on my memory of what we decided, there are two things I noticed that I want to check on whether they were deliberate. If they are deliberate, then that's fine and let's keep them for now and address them later. But I want to point them out in case your patch meant to do something different, in which case perhaps we should fix before backporting.

  • On desktop only
    • When I arrive on the article in read mode with the panel open in locked mode (as expected)
    • Then I interact by clicking on a tip,
    • Then I click Edit,
    • The panel stays on the same tip (as expected)
    • But it also stays in locked mode (unexpected)
    • Then if I close the panel and open it again (all while staying in Edit mode), it switches to unlocked mode.
  • Desktop and mobile
    • After I click edit and navigate to the root screen
    • Then, while on the root screen, I switch the article back to read mode,
    • And then I click to go to the suggested edits screen from the root screen,
    • The suggested edits screen is in locked mode, so I can't navigate back to the root screen from where I just came.

Change 604599 had a related patch set uploaded (by Gergő Tisza; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.35.0-wmf.36] Help panel: Update guidance behavior rules

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

@kostajh (cc @Tgr @Catrope @Etonkovidova) -- I just went through and tested on beta, and I think that new patch mostly puts us in a good place! Thank you for working on it. At this point, we have been tweaking the business rules in so many places (Phab, email, Slack) that we no longer have a canonical set of rules to test against. Do you think you could write down in bullet points what we should expect to see in the interface post-patch?

Sure! I linked to this earlier but it might have gotten lost -- the patch commit message has a summary of the business rules. I'll copy them here as well:

Business rules:

  • In guidance, track the help panel state so we know which panel the user had opened and which tip was selected. Persist this across page reloads, tab switches, etc.
  • Also, on page reload, open the help panel if it was open before or keep it minimized if it was minimized
  • When guidance is available, ensure that the help panel button is always available, even in Read mode (unlike traditional help panel)
  • When toggling between Read/Edit/Edit Source, show/hide the footer that says "Ready? Click/tap editing..."
  • If the user in read mode changes the state of panel, by toggling tips or navigating which screen they're on, then switching modes should not change the state of the panel. If they have not touched the help panel in read mode then we would want it to animate back to the root screen upon switching to edit mode.
  • Set locked mode for the help panel if the current panel is suggested edits and the page is in read mode.

But based on my memory of what we decided, there are two things I noticed that I want to check on whether they were deliberate. If they are deliberate, then that's fine and let's keep them for now and address them later. But I want to point them out in case your patch meant to do something different, in which case perhaps we should fix before backporting.

  • On desktop only
    • When I arrive on the article in read mode with the panel open in locked mode (as expected)
    • Then I interact by clicking on a tip,
    • Then I click Edit,
    • The panel stays on the same tip (as expected)
    • But it also stays in locked mode (unexpected)
    • Then if I close the panel and open it again (all while staying in Edit mode), it switches to unlocked mode.

I think that was a bit of a gap when I was trying to reconcile the "go to root screen if no interaction" and "stay in locked mode" rules, I will upload a patch to address this. I don't know if we will back port it this week though.

  • Desktop and mobile
    • After I click edit and navigate to the root screen
    • Then, while on the root screen, I switch the article back to read mode,
    • And then I click to go to the suggested edits screen from the root screen,
    • The suggested edits screen is in locked mode, so I can't navigate back to the root screen from where I just came.

Will fix that in the same patch referenced above.

Change 604659 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help panel guidance behavior rule updates

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

Change 604599 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.35.0-wmf.36] Help panel: Update guidance behavior rules

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

Change 604704 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help panel: Refactor mode tracking & remove question poster dialog

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

Some things we discussed on the patch as lacking clear business rules:

  • after saving an edit, the user will see both the post-edit panel and the help/guidance panel (assuming that panel was open when they saved)
  • panel behavior changes after the panel is interacted with (it disables the guidance -> root panel switch on opening the editor) but what counts as an interaction is not fully defined. For example, closing the panel is not currently treated as an interaction.
  • what should happen when cancelling out of the editor? (which has very different mechanics for wikitext and VE/mobile) Does that count as an interaction? Should the panel behavior be the same for VE and wikitext?)

Also, closing the help panel logs a CTA impression now. We probably don't want that.

@kostajh -- thanks for the fixes. I actually meant: could you write down the sum total business rules that we ended up at after all the changes? Like if we wanted to update the task description here? (which is what I want to do). This will help us test and also design things that come after guidance.

@Tgr -- here's what I think for each of the points you raised:

after saving an edit, the user will see both the post-edit panel and the help/guidance panel (assuming that panel was open when they saved)

I just tried this out, and I think this is fine. The post-edit dialog sufficiently covers up everything that I don't think having the help panel open in the background is distracting. Plus, if they click the button to keep editing the article, it will already be open for them, and we don't have to have logic to open it up again.

panel behavior changes after the panel is interacted with (it disables the guidance -> root panel switch on opening the editor) but what counts as an interaction is not fully defined. For example, closing the panel is not currently treated as an interaction.

To be explicit, the behavior that I think should control this behavior is:
I think the way it seems to work right now is the behavior we want: the only "interaction" that counts is clicking on a tip number. Is that how it's currently implemented? If so, then I don't think we need to change anything.

what should happen when cancelling out of the editor? (which has very different mechanics for wikitext and VE/mobile) Does that count as an interaction? Should the panel behavior be the same for VE and wikitext?)

The behavior I'm seeing in production right now is what I was expecting. Regardless of the editor, it looks like if I'm in the editor and then switch back to read mode, the panel continues to display what it was showing before. Could you describe the different mechanics you mentioned?

Also, closing the help panel logs a CTA impression now. We probably don't want that.

I agree that we don't want that. Should we file a task for it? Could you file it please?

For Design review - the items marked with :

Two items are about handling the situation when VE is not a default editor (and some ongoing discussion how to handle user preferences)

On single-tab editor wikis, users who click edit from the newcomer tasks workflow should have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings. [...]

Users who click the edit pencil should have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings. [...]

The preference for an editor (VE vs source editor) depends on previous, successfully saved user edits. The editor where that edit was made becomes a default editor (and a single tab)

That's how is implemented kowiki betalabs :

  • a user click to edit a non-SE article
  • the popup asks which editor a user prefers - on kowiki betalabs there is no option "display two editors" in that popup
  • a user selects "source editor" and makes an edit
  • a user goes to SE article from the Homepage - only one tab (the source editor is present); the blue dot is present too (which is right)
  • when in editing mode, a user switches to VE and saves an edit in VE; the next SE article selected from the post-edit dialog will have two editor tab.
  • the user goes to the Homepage, changes the difficulty level, clicks on the article - will be presented only with VE tab.

On cswiki betalabs - a new user is immediately presented with two tabs, but still there will be a popup asking whether a user wants to switch to another editor type.

We can check related editor settings on wikis where Homepage is deployed to see if the behavior of handling user preference for editor is consistent with the scenario above.

For Design review

When on a "branch", the panel should display a "Back" button in the lower left, that causes the panel to swipe animate back to the "root content".

Does it mean "a "Back" button in the upper left"? Both mockups - for the desktop and for the mobile - show the currently implemented behavior of the back arrow button in the upper left corner.

Screen Shot 2020-06-12 at 4.58.51 PM.png (494×387 px, 41 KB)

(1)
(minor)

On both platforms, there should be a pulsing blue dot on the lower right of the edit call to action [...]

It's implemented on mobile, on desktop the blue dot is placed in the middle of the edit option (which seems to be a standard option)

Compare:

mockupimplemented
Screen Shot 2020-06-11 at 4.51.13 PM.png (686×591 px, 115 KB)
Screen Shot 2020-06-11 at 4.50.45 PM.png (579×654 px, 93 KB)

(2) From the above screenshots - is it still ok the width of the guidance/help panel? The mockup presents a much narrow panel. I remember that it's been discussed before.

(3) Steps #3 and #4 from this @MMiller_WMF comment have been implemented. I did not see any problems with preserving the state of the panel according to a user actions and the business rules - minimizing, the rood screen etc.

Notes:

  • it feels a little inconsistent to see an animation to the root screen only if a user clicks 'Edit' when on the first tip
  • on mobile, when a user lands on a SE article page and sees a sliding drawer with guidance and a blue dot, clicking on a blue dot (a perceived click, from a user's perspective) would just dismiss the drawer, not opening an editor (as a user might expect). Although the blue dot is still there to indicate that an additional click is needed. The mobile mockup actually illustrates the same behavior.

A very minor issue that has been introduced at some point with storing help panel state in the session: if you post a helpdesk question and then reload the page, the help panel will reopen with the same panel (success message after posting) but the text will be wrong (it will always assume this is the user's first post).

Not sure if it's worth the effort fixing, but maybe the questioncomplete state could revert to home or ask-question when recreating the panel after a page load.

Change 604704 abandoned by Kosta Harlan:
Help panel: Refactor mode tracking & remove question poster dialog

Reason:
Moved this into the parent patch

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

I realize I'm kind of confused now about where we've landed (i.e. is "locked" mode still a desirable thing?), especially after the rules have changed a bit in T255254.

@RHo and @MMiller_WMF could you please review the help panel behavior in beta labs for 1) regular help panel, not part of any suggested edit session, 2) Special:Homepage, as seen when posting a question to your mentor, and 3) in the suggested edit guidance session -- and do that for both desktop and mobile -- and then let us know which changes you want to see in business rules?

Sorry to cause more work but I feel like it might be easier to start with fresh eyes now that we've added the close button.

I realize I'm kind of confused now about where we've landed (i.e. is "locked" mode still a desirable thing?), especially after the rules have changed a bit in T255254.

@RHo and @MMiller_WMF could you please review the help panel behavior in beta labs for 1) regular help panel, not part of any suggested edit session, 2) Special:Homepage, as seen when posting a question to your mentor, and 3) in the suggested edit guidance session -- and do that for both desktop and mobile -- and then let us know which changes you want to see in business rules?

Sorry to cause more work but I feel like it might be easier to start with fresh eyes now that we've added the close button.

Looking over it all again myself, I think the only business rule difference between my patch and what is in beta labs right now is that in beta, guidance opens as "Locked" but with my patch there is a back arrow in addition to the X in the top right. Do we want to keep locked mode for the suggested edits screen or get rid of the concept?

Everything else in my patch is shuffling code around to (hopefully) make things easier to update in the future.

I realize I'm kind of confused now about where we've landed (i.e. is "locked" mode still a desirable thing?), especially after the rules have changed a bit in T255254.

@RHo and @MMiller_WMF could you please review the help panel behavior in beta labs for 1) regular help panel, not part of any suggested edit session, 2) Special:Homepage, as seen when posting a question to your mentor, and 3) in the suggested edit guidance session -- and do that for both desktop and mobile -- and then let us know which changes you want to see in business rules?

Sorry to cause more work but I feel like it might be easier to start with fresh eyes now that we've added the close button.

Looking over it all again myself, I think the only business rule difference between my patch and what is in beta labs right now is that in beta, guidance opens as "Locked" but with my patch there is a back arrow in addition to the X in the top right. Do we want to keep locked mode for the suggested edits screen or get rid of the concept?
Everything else in my patch is shuffling code around to (hopefully) make things easier to update in the future.

IIRC we decided to scrap the 'locked' idea both for code simplicity, and since we will be enabling users to more easily close and go back from the guidance screen on T255254. @MMiller_WMF please confirm if I remember correctly.

Change 603455 abandoned by Kosta Harlan:
DNM: Help panel: track tab interactions in state

Reason:
we did this in another patch

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

@kostajh @RHo -- (said in chat, but posting on Phabricator for posterity) that's right, now that we have the new navigation buttons, we do not need locked mode anymore. We only had it on temporarily because locked mode alleviated a specific situation: on mobile in read mode, in which the user would have to navigate back to the root screen just to close the panel and look at the article to click edit.

Change 604659 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help panel: Remove locked mode and refactor code

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

I think what's described in the task is done. Some other things raised in the comments that might need follow-up (but don't really belong to this task):

Also, closing the help panel logs a CTA impression now. We probably don't want that.

I agree that we don't want that. Should we file a task for it? Could you file it please?

Since T255255: Newcomer tasks: Enable easier toggling to open and close Desktop help panel is happening soon, this will probably take care of itself (the extra impression is only happening because we are removing / readding the CTA button now).

Reviewed the items that are marked with

(1)

On both platforms, there should be a pulsing blue dot on the lower right of the edit call to action (see T244435: Newcomer tasks: guidance blue dot).

T244435 is closed as Resolved. Based on @RHo comment on the task, positioning the blue dot centrally on "Edit" label (Desktop) is fine.

(2) These two (related) issues will be addressed in a different phab task.

On single-tab editor wikis, users who click edit from the newcomer tasks workflow should have the visual editor open, as opposed to wikitext.

Users who click the edit pencil should have the visual editor open, as opposed to wikitext. This should happen regardless of their previous editor settings.

Taking also into account the above @Tgr comment above - this task is essentially Done.

I think the only events I really care about are the impression and open actions, as they make it easy to identify when the edit context interactions would start. If the user had the Guidance screen open and then clicks "Edit", will we log both an impression and an open event, or would it just be the latter?

If the user edits via VE or mobile, we don't log either. If they edit via wikitext (so there's a page reload), we log both (but the impression event will probably go away after T255255).

If the user edits via VE or mobile, we don't log either. If they edit via wikitext (so there's a page reload), we log both (but the impression event will probably go away after T255255).

Okay, just so I'm understanding this correctly: we're moving to a setup where if the user sees the Help Panel in a reading context, then the impression event happens when the page loads and we'll not log an additional event when the editor is loaded. If the user didn't have it already available and opens the editor (e.g. on an article that isn't a suggested task), then the impression event happens when the editor is loaded. Did I get that right?

I checked the suggested measurements for Guidance and compared them to the schema, and noticed that since we have the context field available we'll be able to answer all the questions there. So this is good to go from that perspective.