After the user selects an "add links" task from the suggested edits feed, the next thing they will experience is three onboarding screens.
* **When and where**
** On mobile, onboarding will cover the whole screen. It should be the next thing the user sees after selecting a task. They should //not// first see the article they selected and then see the onboarding cover it up.
** On desktop, onboarding will be in modals on top of the article they selected. Those modals should be present when they arrive on the article. They should //not// pop up over the article after the article loads. Behind the modals, the user should see a greyed-out article. Ideally, the link inspector for the first suggested edit should already be there and waiting for them, but this is not required.
** Note that the copy for the mobile and desktop should be identical, even in places where the copy in the mockups differs.
* **Navigation**
** There will be three screens, each with a header, graphic, another header, and a body.
** Each screen has an "X" to close it. When closed, the user should be on the article they selected, ready to do the first link suggestions.
** On desktop, clicking outside the modal should not close it. Only clicking the "X" should close it.
** Navigating through the three screens will advance a "three bubbles" graphic under the header, with a bubble filled in for each screen, and saying "1 of 3", "2 of 3", "3 of 3".
** The first screen should have a "Don't show again" checkbox in the lower left. Until the user checks this, the onboarding should show up every time they start a new "add links" task. This "don't show again" will not apply to other task types, such as "add images". Those will have their own "don't show again". The checkbox can "count" as soon as it's checked, or only if the user completes the onboarding -- that can be up to engineers.
** In the lower right of the screens is the progressive button to advance to the next screen. On the first two screens, it will be an arrow. On the third screen, it will say "Get started".
** In the lower left of the second and third screens is an arrow button to go back to the previous screen.
** There should be sliding transitions as the user advances and goes back through the screens.
* **Screen 1**
** Header: "Introduction"
** Graphic: moon article with two callouts.
** Another header: "Adding links helps people navigate to topics they want to learn more about."
** Body: "In this task, you will decide whether words in one Wikipedia articles should link to other Wikipedia articles."
** Example:
*** Next, there will be a box with an example sentence in it, showing some highlights where wikilinks might go.
*** Sentence: "The moon is the only natural satellite that orbits around the Earth."
*** Highlights: "natural satellite", "orbits", "Earth".
*** There should be grey italics above the example saying, "Example sentence".
** More body: "No special knowledge about the article is needed to do the task."
* **Screen 2**
** Header: "Introduction"
** Graphic: robot who thinks the moon is made of cheese.
** Another header: "Suggested links come from artificial intelligence (AI), which can make mistakes."
** Body: "AI might suggest links on words that don't need them, or might suggest linking to the wrong article. You'll use your judgment to decide where it is right and wrong.
** More body: "You can reject bad suggestions, skip when you're unsure, or provide a better link."
** Link at bottom: "Learn more about AI suggestions". Link target TBD.
* **Screen 3**
** Header: "Introduction"
** Graphic: some highlighted links
** Another header: "Guidelines for linking articles"
** Body: a list with the following bullet points.
*** "Link concepts that a reader might want to learn more about.
*** Make sure the suggested article is the right destination for the highlighted text. (e.g. in "Saturn is well-known for its rings", "rings" might link to the article "ring system".
*** Only link to the first time that word or phrase occurs in the article.
*** Don't link common words, years, or dates.
*** If in doubt, skip the suggestion.
* **Implementation notes**
** Here are some ideas from engineers about how to make sure the users sees the onboarding before they see the article:
*** //"One way we could probably mitigate this is hide/obscure the article while the page and the script load, so that the user would see a blank page (or some sort of spinner animation) while they wait for the onboarding to arrive."//
*** //"Another idea would be to show the onboarding dialog on Special:Homepage, and “Get started” takes you to the article opened in Edit mode. Although the default behavior in opening a page in Edit mode is to show the article then dim the background while the editor loads. But if we show the dialog on Special:Homepage then we can’t preload the editor, which causes a performance slowdown."//
*** //"We could top load it, but that comes with some performance sacrifice."//
*** //"On desktop, the onboarding is a modal over the article. So we might end up with a divergence in implementation."//
** [TASK GOES HERE] specifies how this same content should be made available in the help panel once the user has started the task, like how we make "quick start tips" available for classic maintenance template tasks. Perhaps, on mobile at least, the onboarding should actually show up via the help panel, the same way that quick start tips show up for maintenance template tasks.
** //"Technical musing: while the user is viewing the onboarding, we should preload the VE code, the article's Parsoid HTML and the link suggestion data. That way the user won't have to wait long for the editor to load once they hit the "Get started" button."//