Page MenuHomePhabricator

Add a link: delay the intro pop-up animating on until after VisualEditor loads
Closed, ResolvedPublic

Description

Following up from discussions in the comments in https://phabricator.wikimedia.org/T269638#6985191, it is jarring when the editing toolbars and cards are loading on Desktop under the intro pop-up, so we should change the timing of the onboarding dialog to be later.

On desktop, the onboarding dialog should appear after the progress bar for VisualEditor finishes. Link inspector should only show up upon closing the dialog.

Event Timeline

Hi @RHo & @MMiller_WMF — this is a new task that came out of the discussions in T269638: Add a link: Suggestions mode.

I wanted to make sure to call out that some of requirements defined in T269490: Add a link: onboarding will no apply with the changes for this task.

On desktop, onboarding will be in modals on top of the article they selected. We want those modals to load as soon as possible when they arrive on the article. Behind the modals, the user should see a greyed-out article.

"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."

Another clarification: on mobile, is this not an issue since the modal covers the entire screen (so no changes are needed for mobile)?

Change 679020 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: Show onboarding after link inspector is shown

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

Change 679020 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: Show onboarding after link inspector is shown

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

Hi @RHo & @MMiller_WMF — this is a new task that came out of the discussions in T269638: Add a link: Suggestions mode.

I wanted to make sure to call out that some of requirements defined in T269490: Add a link: onboarding will no apply with the changes for this task.

On desktop, onboarding will be in modals on top of the article they selected. We want those modals to load as soon as possible when they arrive on the article. Behind the modals, the user should see a greyed-out article.

"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."

hi @mewoph, in case it helps I have added the ideal behaviour here in a short demo - whereby ideally it would scroll to and open the inspector only after the onboarding is closed:
https://youtu.be/uYXpPLwNubg

Another clarification: on mobile, is this not an issue since the modal covers the entire screen (so no changes are needed for mobile)?

Yes that's right, no changes are needed for mobile.

Thanks for the demo @RHo! One clarification: in the demo, the onboarding modal pops up right after the toolbar is set up. Here's what that looks like in situ. Should it show up after the progress bar finishes? It looks a bit like the modal is pausing the progress when the bar is behind it and hasn't fully loaded.

Before progress bar finishes:

After progress bar finishes:

Thanks for the demo @RHo! One clarification: in the demo, the onboarding modal pops up right after the toolbar is set up. Here's what that looks like in situ. Should it show up after the progress bar finishes? It looks a bit like the modal is pausing the progress when the bar is behind it and hasn't fully loaded.

Before progress bar finishes:

After progress bar finishes:

Hi @mewoph - I confess my demo used a modified screencast of an actual loading state where there was this jolt from when the progress bar was about 70% loaded to it disappearing abruptly with the editor loaded, but in answer to your question yes I agree the onboarding should appear after the progress bar is done and editor is loaded. However, is there a relatively simple way to prevent this 'stalling' of the progress bar happening at ~70% for a good 5-6 seconds? If not simple, and/or if it falls outside the realms of this task, we can file as a separate issue. Thanks!

For the progress bar stalling, I'm not sure if this is an issue unique to this context since I saw the same behavior when I tried to edit an article without link recommendations.

Moving back to In Progress to update the timing

mewoph renamed this task from Add a link: delay the intro pop-up animating on until after the editing toolbar and link inspector card loads to Add a link: delay the intro pop-up animating on until after VisualEditor loads.Apr 15 2021, 3:57 PM
mewoph updated the task description. (Show Details)

Change 679873 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Add a link: Show onboarding after VisualEditor loads

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

Change 679873 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Add a link: Show onboarding after VisualEditor loads

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

Etonkovidova subscribed.

For @RHo review
Here is a screen recording form betalabs

Notes (from my testing and watching @mewoph video in the above comments)

  • the initial loading displaying an article in Read mode takes some time, so a user is presented with an article in non-interactive mode
  • the progress bar adds visual noise and doesn't actually signal anything useful.

For @RHo review
Here is a screen recording form betalabs

Notes (from my testing and watching @mewoph video in the above comments)

  • the initial loading displaying an article in Read mode takes some time, so a user is presented with an article in non-interactive mode

Thanks @Etonkovidova - I agree that the initial Read is adding time, can we have the article load on Edit straightaway @mewoph to save time? Happy to close this and open a separate task for post initial launch if so.

  • the progress bar adds visual noise and doesn't actually signal anything useful.

It looks like even when loading the page with editor directly, it takes time for it to load so it is important to have the progress bar to signify that something is happening:

editor-on-load.mov.gif (1×1 px, 2 MB)
open to see animated gif

Hi @RHo — loading the article right away should be possible. I think there will be some additional work to ensure that on mobile, when the user closes Suggestions mode, they are taken to the article's read mode rather than back to the homepage. I went ahead and created T280991: Add a link: open the article in edit mode right away — feel free to add/edit. Thanks!

Thanks @mewoph for filing T280991 - resolving this one as it is done per acceptance criteria.

Hi @RHo — loading the article right away should be possible. I think there will be some additional work to ensure that on mobile, when the user closes Suggestions mode, they are taken to the article's read mode rather than back to the homepage. I went ahead and created T280991: Add a link: open the article in edit mode right away — feel free to add/edit. Thanks!