Wp-calypso: [Gutenboarding]: ensure that we prevent multiple site creation during the onboarding flow

[ramonjd]

The signup framework contains a long-standing "feature" that allows multiple site creation during onboarding. (/start)

How to recreate

It looks like the common way to trigger this issue is to navigate back in the browser during or after site creation (e.g., from checkout), then continue the flow.

Every time users go to the checkout page, we create a site. So if they go back and forth and change plans for example, they end up with a new site on the account every time they do this.

Why we need to fix this in Gutenboarding

Users get confused about this. They might have purchased the Business plan for their site for example, but with three sites now, they might be looking at the “Free” site in calypso now, and they don’t know how to “Switch Site”.

This is frustrating for both users and HEs. People often tell me, “I don’t know why I have two sites,” or they’re confused about why the plan they paid for isn’t showing on their site (because they’re on the wrong site).

See paObgF-7A-p2 and paObgF-JO-p2 for context

Related slack chats:

p1580843764312500-slack-CNMU1UHHB
p1580819414294000-slack-CNMU1UHHB

Implementation details

We'll need to track site creation status, and prevent new site creations in the same session.

If the user returns to the onboarding flow, we could check the store (or hit me/sites) to check if they have created a site in the current gutenboarding session, If they have, we could:

• ask them if they'd like to continue with that site or
• ditch the site and create a new one
• don't say anything, just continue with that site, assuming that they'll see it in the domain picker anyway.

At all times we should make it clear to the user what is happening, or give them choices to continue. If they want to create a new site, we should allow that.

If they navigate away from checkout, we'll need to make sure that the selected site or any new site is applied to the cart.

[ockham]

If the user returns to the onboarding flow, we could check the store (or hit me/sites) to check if they have created a site in the current gutenboarding session, If they have, we could:

• ask them if they'd like to continue with that site or
• ditch the site and create a new one
• don't say anything, just continue with that site, assuming that they'll see it in the domain picker anyway.

I have a strong preference for the third option, followed by the first. I think if a user returns to Gutenboarding, and they're already logged in (since they created an account the last time around), we should show their 'default' site (like we do in Calypso). For new users, that will be only the site they just created recently anyway.

This raises a few UI questions tho:

• Once they've created a site, what do we show people if they access /gutenboarding (or whatever we'll call that route in the future)?
  
  
  
  • Do we show them the intent gathering and design picker steps again? Those arguably give a sense of 'starting from scratch', and we'd need to communicate the changes they make their to the exisiting site (e.g. changing the site title; or, less trivially, the domain name)
  
  
  • With the domain name in particular, there's quite the diffence between the state of the domain picker prior to site creation (this is your currently selected domain name that will be used to create your site) vs after (this is your site's actual domain -- changing it is kind of a big step).
  
  
  • Alternatively, we could direct them to post-creation state (i.e. FSE), where they can make all the same changes (albeit through different UI elements). This makes some sense, but now we're facing the edge case of a logged-in user (that might've used our product for longer) actually _wanting_ to create a new site -- in which case we obviously don't want to redirect them away from the initial /gutenboarding steps.
  
  

Whatever solution we decide on should also take into account that the onboarding flow might be modified in the future -- e.g. additional steps might be added.

cc'ing @simison @johnHackworth and designers @olesyabrk @dwolfe

[simison]

Once they've created a site, what do we show people if they access /gutenboarding (or whatever we'll call that route in the future)?

So does the problem occur when we empty all the onboarding values after the site has been created, and they're starting from scratch to create another site when entering the flow again? Somehow in between they didn't realize that the site already got created for them?

And if we don't empty the values, folks who genuely are creating a new site get confused because they see old values?

[simison]

and we'd need to communicate the changes they make their to the exisiting site (e.g. changing the site title; or, less trivially, the domain name)

The linear onboarding flow shouldn't be used to modify existing sites, that'll get too confusing pretty quickly. The way to modify existing site with these same components shouldn't be linear, instead, they access them somehow via Editor interface. Imagine e.g. "change design" button somewhere.

[ramonjd]

So does the problem occur when we empty all the onboarding values after the site has been created, and they're starting from scratch to create another site when entering the flow again?

I think it's more mundane than that.

In the current signup framework, when you navigate back to signup after the site creation step (the step with the blurry, flying things) after checkout but before Customer home, the store still contains all the data necessary to create a site.

Moving forward again through the site creation step will just use that stored data create a new site.

[simison]

Yeah, I think things should be clear if:

• The site gets created → we empty all the values
• If user navigates back, entering mid-gutenboarding flow somehow...
• ...we throw them back to the beginning of the Gutenboarding flow (intent gather) with empty values so that it's clear they're starting from scratch

[ramonjd]

More discussion and context
pbAPfg-5U-p2
pbAPfg-5U-p2#comment-270

[andrewserong]

Just a heads-up that I've just added myself as an assignee and have started exploring in #39794 to get sense of how some of the different options might feel, but totally happy for anyone else to jump in if anyone has strong ideas. The PR is nowhere near ready (and isn't yet functional), just wanted to give a gentle wave that I'm looking into it 👋.

[ramonjd]

Just a heads-up that I've just added myself as an assignee and have started exploring in #39794 to get sense of how some of the different options might feel

I, for one, approve this with full _oomph_

[andrewserong]

I've whipped my PR (https://github.com/Automattic/wp-calypso/pull/39794) into shape ready to be tested / a preliminary review or feedback on the direction. Totally happy to go with a different direction for this, too — think of this as an exploration down one particular avenue for dealing with the issue :)

[ramonjd]

We've done as much work as we can on this for now. 👍