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:
* [[ https://oacaib.axshare.com/ | Desktop prototype ]]
* [[ https://ny2e57.axshare.com/ | Mobile prototype ]]
NOTE: For redlined design specs see the [[ https://zpl.io/a3KgRQA | 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**
* The page should be in read mode, not edit mode.
* All popups, notices, and Guided Tours should be suppressed (see {T235566}).
* On desktop, the panel should animate open and display the "suggested edit screen" (see {T244541}).
* On mobile, the "mobile peek" should animate open (see {T244434}).
* On both platforms, there should be a pulsing blue dot on the lower right of the edit call to action (see {T244435}).
* On desktop, the user may minimize and reopen the panel.
* On mobile, after passing through the "mobile peek" stage, the user may minimize and reopen the panel.
**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. If it was minimized, it should remain minimized.
* 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**
* The "post-edit dialog" should display (see {T245790}).
* All other post-edit notices or toasts should be suppressed.
**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