Launchpad - add handling for new add_first_subscribers task.

[Addison-Stavlo]

Related to # Automattic/loop#252 and Automattic/loop#253 and pe7F0s-2mv-p2

Proposed Changes

Adds handling for a new task on the write launchpad ("Publish a blog" goal).

• Adds the add_first_subscriber task to the TASKS_TO_COMPLETE_ON_CLICK array, to ensure this task is markes as complete once clicked. This handles the completion from the calypso / my-home side.
• Adds a addFirstSubscribersTask action to the stepper launchpad task definitions, applying similar handling to the full-screen launchpad in stepper.
• Adds the subscribers step in the fullscreen/stepper launchpad flow for 'write' to be used with this task in the fullscreen version.

On my home:

In stepper onboarding:

Why are these changes being made?

• We want to give the blogger launchpad a task to add subscribers. However, this task is intended to be more of a nudge and discoverability, rather than a hard requirement to add subscribers in this context. Therefore we set completion on clicking the task, as opposed to later on when subscribers are added.

Testing Instructions

• Follow the instructions to patch Blogger Launchpad - add add_first_subscribers and verify_email tasks. jetpack#41502 to your sandbox.
• sandbox the public-api
• Run this calypso branch.
• Create a new site.

1. Test full-screen launchpad flow:

• On the goals page, select "Publish a blog".
• Follow the flow to the fullscreen launchpad that appears.
• Click the "add your first subscribers" task.
• Verify this goes to the full-screen subscribers form onboarding page.
• From here, whether you click to submit adding new subscribers or skip, this should lead back to the launchpad with the "add your first subscribers" task is marked as complete.
• Click the task again to test whichever functionality you didn't (skip vs. add), and ensure it works and leads back to the fullscreen launchpad as expected.
• Smoke test the launchpad flow and launch your site.

2. Test my-home launchpad flow (1):

• Create another new site the "Publish a blog" goal.
• Once arriving at the fullscreen launchpad, click the "skip" link in the top right to dismiss the fullscreen launchpad.
• Now in my home, select the "add your first subscribers task".
• Verify it loads the subscribers page with modal open.
• DO NOT ADD SUBSCRIBERS. Close the modal and go back to my home.
• Verify the task is marked as complete.
• Go back to the users->subscribers page. Verify the checklist item to add subscribers here is NOT complete, as we did not actually add any subscribers.

3. Test my-home launchpad flow (2):

• Create another new site the "Publish a blog" goal.
• Once arriving at the fullscreen launchpad, click the "skip" link in the top right to dismiss the fullscreen launchpad.
• DO NOT click the launchpad. Instead go to Users->subscribers in calypso.
• Select "add subscribers" and add a couple subscribers.
• Verify the checklist on users->subscribers shows the add subscribers task as complete.
• Go back to the launchpad in my-home. Verify the "add first subscribers" task is also marked as complete.

This is the separate subscribers checklist on users->subscribers mentioned in the 2 testing flows above. The point of this in the test is that adding subscribers without use of the launchpad checklist should check off both this task and the new task we added on the my home launchpad, BUT clicking the new my home launchpad task and bailing without adding subscribers should only mark off the my home launchpad task and not this one:

4. Test with a new user / unverified email account

• Do the same flows as above on an account without a verified email address.
• Verify the launchpad shows a verify email task and that the subscribers task is disabled until email is verified.
• Verify other tasks past this are still usable (editor, launching) and that it does not hard block the flow.
• Smoke test email verification, but note we have not changed any of its logic here.

5. Smoke test without the jetpack diff on the sandbox.

• This tests how this will behave after this code is merged and waiting for the task definition to be shipped in jetpack-mu-wpcom.
• The flows should behave the same as they do in production right now.

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
  • For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-131948

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-131948&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-131948&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• notifications
• odyssey-stats

To test WordPress.com changes, run install-plugin.sh $pluginSlug add/first-subscriber-task-completion-on-subscriber-modal-opening on your sandbox.

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~96 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-stepper               +244 B  (+0.0%)      +92 B  (+0.0%)
entry-subscriptions         +126 B  (+0.0%)      +59 B  (+0.0%)
entry-main                  +126 B  (+0.0%)      +63 B  (+0.0%)
entry-login                 +126 B  (+0.0%)      +59 B  (+0.0%)
entry-domains-landing       +126 B  (+0.0%)      +59 B  (+0.0%)
entry-browsehappy           +126 B  (+0.1%)      +59 B  (+0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~13017 bytes added 📈 [gzipped])

name                           parsed_size            gzip_size
write-flow                       +191594 B  (+16.2%)   +61572 B  (+17.2%)
people                              +260 B   (+0.0%)      +41 B   (+0.0%)
link-in-bio-tld-flow                +232 B   (+0.0%)      +46 B   (+0.0%)
build-flow                          +232 B   (+0.0%)      +46 B   (+0.0%)
transferring-hosted-site-flow        +24 B   (+0.0%)       +8 B   (+0.0%)
subscribers                          +24 B   (+0.0%)       +9 B   (+0.0%)
home                                 +24 B   (+0.0%)      +11 B   (+0.0%)
earn                                 +24 B   (+0.0%)       +6 B   (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~9 bytes added 📈 [gzipped])

name                                                 parsed_size           gzip_size
async-load-calypso-my-sites-stats-pages-subscribers        +24 B  (+0.0%)       +9 B  (+0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[Addison-Stavlo]

I plan to look at adding a small notice to help lead users back to the fullscreen launchpad - https://github.com/Automattic/loop/issues/252#issuecomment-2633705228

[artemiomorales]

This tests well and code changes seem reasonable to me 👍

[Addison-Stavlo]

Theres one last thing I want to discuss and figure out, this is in regard to the flow for users with unverified emails (as adding subscribers is restricted to users with verified email addresses). For the my-home launchpad, I don't have any issues with displaying the task as enabled regardless as the /subscribers page will communicate the message of need to verify email first. But Id like to discuss options for the stepper/fullscreen onboarding flow:

• Currently (in this PR), we are showing the task as disabled if the email is not verified. I followed this behavior from another existing subscriber task, but later realized that it may make more sense in another flow with a conditional verify-email task before it. However, I don' think we want to add the weight of requiring email verification in blogger onboarding. This current behavior does handle our concerns, but may feel a little odd to a user coming through and wondering why that task is disabled:

• Another option could be to enable the subscriber task here regardless. The form will not allow unverified users to add subscribers and does have a note about the verification requirement. We are also marking the task as complete whether the user adds subscribers or skips from here, so the verification req seems non blocking to their flow. Maybe the user sees the note about email and goes to verify it and then continues onto their launchpad experience to add subscribers...

• A third option could be to hide the task entirely in this fullscreen case if email is not verified. I don't think the stepper launchpad specifically has a systematic way to hide a task like this, but it seems simple to add if we need. This option doesn't seem great since it removes all promotion of the idea of adding subscribers for these users, so maybe better to avoid.

I wonder if @davemart-in or others have thoughts. Im starting to lean towards the second idea. Although it maybe good to follow up a separate PR on the subscribers form to have a better message than "The user's email..."

[davemart-in]

@nuriapenya bringing you into this discussion in case you have thoughts. My thought would be to add the "Verify email" step prior to the "Add your first subscribers" step.

@Addison-Stavlo yeah, this stood out to me as well:

The user's email address has not been verified

I'd go with something like:

You must verify your email prior to adding subscribers

[Addison-Stavlo]

My thought would be to add the "Verify email" step prior to the "Add your first subscribers" step.

I was initially concerned that could add more weight and friction to the blogger flow, and potentially have a higher impact on completion rates. But maybe it would be ok as long as its not a blocking requirement for the user (they can still skip over it and carry on to publish posts and launch their site either way).

[nuriapenya]

Heya @davemart-in @Addison-Stavlo 👋🏼

For this specific PR, the second option seems the most reasonable one but bear in mind we will be soon removing the stepper launchpad in favour of the focused one in my home (#98245). And in this case, yes, this task should be the very first one in the list, before the subscribers one.

My copy suggestion was:

Verify email address
Secure your account and enable key features.

I pinged you both on Slack in a convo I started around this task :)

[Addison-Stavlo]

bear in mind we will be soon removing the stepper launchpad in favour of the focused one in my home

I saw that! Although I saw it was paused temporarily so wanted to make sure we had the fullscreen stepper flow working well in the mean time. 😄

[Addison-Stavlo]

For this specific PR, the second option seems the most reasonable one but bear in mind we will be soon removing the stepper launchpad in favour of the focused one in my home (#98245). And in this case, yes, this task should be the very first one in the list, before the subscribers one.

I think I wrote these options in an ambiguous way, and I didn't list having verify email task as an option there originally. But since then I have started coming to the conclusion that having the verify task here will be the right things to do. That seems to be what you are saying here and in slack as well, so im on board!

[Addison-Stavlo]

The backend code corresponding to this PR was just updated to:

1. Add the 'verify email' task.
2. Add more completion logic to add_first_subscribers that accounts for other subscribers tasks. That is, if a user adds subscribers outside of this launchpad or through another task list, add_first_subscribers should be marked as complete.

The testing instructions have been updated here.

[DustyReagan]

All the test cases are working as expected for me, and a general smoke test looks good, too!