Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Onboarding: Remove “Confirm store requirements” step if possible #2493

Closed
2 tasks
Tracked by #2458
joemcgill opened this issue Aug 5, 2024 · 9 comments · May be fixed by #2568
Closed
2 tasks
Tracked by #2458

Onboarding: Remove “Confirm store requirements” step if possible #2493

joemcgill opened this issue Aug 5, 2024 · 9 comments · May be fixed by #2568
Assignees
Labels
status: on hold The issue is currently not prioritized.

Comments

@joemcgill
Copy link
Collaborator

Part of #2458

Image

Once the Pre-Launch checklist is removed from the StoreRequirements page, the only thing this page is for is verifying store contact info (i.e., phone and address). In cases where we already have a verified phone number and address, we don't need to include this step in the onboarding.

If we can already determine that we have a verified phone number and an address associated with the store, don't show this step during onboarding and move directly to Campaign creation after Configuring Product listings (or whatever step comes before confirming store requirements). These values can be modified in the settings screen after onboarding if needed.

Acceptance Criteria

  • When the onboarding app loads, the Confirm Store Requirements step is not included if the phone number is verified and the MC address is the same as the store address.
  • If the phone number isn't verified, or if the address isn't the same in MC and WC, include the step and show the ContactInformation card with both phone and address cards visible.

Implementation Brief

To check the phone and address info before setting up the setup stepper, we'll need to use the useStoreAddress() hook in js/src/setup-mc/setup-stepper/saved-setup-stepper.js. We know we have a valid phone number when both there is a phone_number value and phone_verification_status is "verified". We know the address is valid when we have a mc_address value and the is_mc_address_different value is false.

When all those conditions are met, we can update the SavedSetupStepper to remove the store_requirements step from the stepper (reference). We'll also need to update the handleSetupListingsContinue() callback so that it calls continueStep( stepNameKeyMap.paid_ads ) instead of continueStep( stepNameKeyMap.store_requirements ) if the store requirements are not being included.

Test Coverage

Update the E2E tests for step 2 of the onboarding (tests/e2e/specs/setup-mc/step-2-product-listings.test.js) to include two scenarios for the continue button:

  1. The current scenario that confirms that clicking continue results in showing the Confirm store requirements page if we don't have a verified phone and address.
  2. A new scenario that confirms that clicking continue shows the Campaign Setup step if we already have a verified phone and address.

Definition Questions

@mikkamp
Copy link
Contributor

mikkamp commented Aug 6, 2024

When the onboarding app loads, the Confirm Store Requirements step is not included if the phone number is verified and the MC address is the same as the store address.

Would it be better to get a decision from UX here? I can see reasons why we'd want to leave the step but just skip it and mark it as completed if the right conditions are met. One such reason is since they are numbered, documentation / references to step number won't match anymore. It also takes away the opportunity to manually verify the contact details are correct (if it's skipped then the Merchant can still click on the completed step to verify).

@joemcgill joemcgill added the needs design The issue requires design input/work from a designer. label Aug 8, 2024
@joemcgill
Copy link
Collaborator Author

Good suggestion @mikkamp. I've marked as needs design so we can follow up. If we keep the step visible, we'll need to check for whether we have a valid phone number and address as part of the handleSetupListingsContinue() callback and skip directly to the paid_ads step we just won't remove the step.

@joemcgill
Copy link
Collaborator Author

After discussing with @fblascogarma, @MatthiasReinholz, and @michaeleleder, the consensus is that if we've already determined that we have a valid phone number and matching address, that this step should not show at all in the UI, so we can move forward with this task as already described in the issue description.

@joemcgill
Copy link
Collaborator Author

I realized that this might need a rethink during my last review of the PR being worked on here. I've left the details here: #2568 (review).

@joemcgill
Copy link
Collaborator Author

@fblascogarma and @MatthiasReinholz, I think we need to reconsider this earlier suggestion about leaving the step in the onboarding flow and automatically marking it as completed and skip to the next step if we can determine that all of the requirements are met.

Reason being, we won't know if someone has a valid phone number and address on their MC account until after they've completed step 1 (connecting their accounts). This means that most people will start the onboarding with the confirm store requirements step visible and we've found that removing that step after onboarding has begun creates an visually awkward experience (see the related conversation on the PR)

@joemcgill joemcgill added the needs feedback The issue/PR needs a response from any of the parties involved in the issue. label Sep 10, 2024
@joemcgill joemcgill removed the needs feedback The issue/PR needs a response from any of the parties involved in the issue. label Sep 24, 2024
@joemcgill
Copy link
Collaborator Author

To resolve this issue, since we only know if we have all of the store requirements for MC after the user has completed step 1, we're going to keep step 3 visible in the stepper and skip it if the requirements are already met. As a future enhancement, we're considering moving the address info directly into step 1 so this step can be removed completely—#2602.

@fblascogarma
Copy link
Collaborator

Hey Joe, can't we work directly in that change we agreed (re: moving address when needed to step 1 and completely remove step 3)? This version is the one we need to launch.

@joemcgill joemcgill added the status: on hold The issue is currently not prioritized. label Sep 26, 2024
@joemcgill
Copy link
Collaborator Author

Hey Joe, can't we work directly in that change we agreed (re: moving address when needed to step 1 and completely remove step 3)? This version is the one we need to launch.

Since #2602 is still in design, we were trying to resolve this one so we had a viable fallback plan if we needed to ship an initial iteration. After chatting with @fblascogarma today, we agreed that a better fallback would be to move this component to step 2 of the flow if needed, so I'm now setting this to on hold until we've decided where that flow will get move do.

@joemcgill
Copy link
Collaborator Author

This will now be handled by #2602, so am closing this issue since it's redundant.

@joemcgill joemcgill closed this as not planned Won't fix, can't repro, duplicate, stale Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: on hold The issue is currently not prioritized.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants