@elizaan36 @pmcpinto

This is going to be a bit tricky/hacky to implement as we don't have access to React components on the plugins page as far as I know.

We can implement it in pure JS, but it's going to take more time than using an already existing React component.

1. Include a custom JS script in WC Payment. The script attaches an event to the deactivation link on the plugins page.
2. Build the modal component in pure JS
3. Popup the modal when the deactivation link gets clicked.

I would say it's 3~5 task.

@samueljseay Hey Sam, do you have any thoughts on this? I'm not very keen on building the modal from the scratch without React, but I don't see any other ways.

Hey Moon, no idea if this is helpful at all but the Heisenberg team have been looking into implementing a similar modal using a Jetpack component. More info in this thread: paJDYF-1Vp#comment-6709

Hey Moon, no idea if this is helpful at all but the Heisenberg team have been looking into implementing a similar modal using a Jetpack component. More info in this thread: paJDYF-1Vp#comment-6709

Thank you @elizaan36 👍

I've read the thread and it looks like the implementation is in React as far as I understand. We won't be able to use React components on the plugin page, unfortunately. I'll discuss with ghidorah team and see if other team members have any other solutions.

@elizaan36 Sorry for the delay in response. I've looked at other plugins that have an exit survey. I think estimate 3 is reasonable for this. We can work on this in the next sprint.

Dev reference: Mailpoet plugin has an exit survey and it can be a good reference.

Hi @elizaan36! Is this something we would still like to implement? If that's the case, should we use the provided survey link or a new one? I can work on it 🙂

@ismaeldcom thanks for the ping on Slack! So I think it would be useful to have it. I think we may want to try and review this survey (perhaps we can make it even more useful). I'll see what I can do and get back to you asap

hey @ismaeldcom ! 👋

Rather than linking to an external survey for this, could we use an inline modal upon deactivation (similar to the one below)? Mailchimp is a good example of this on the plugins page.

If so, I'll confirm the selections we should include in the modal.

Edit: To clarify, the mockup shows some items selected but they would all appear unselected by default to the user.

Hi @elizaan36!

Sure, we're already using the same UI for other surveys, and it will be more consistent 🙂

I'm not sure when we will be able to work on it, but would be good to have all the required information to be implemented.

@anu-rock that seems to be a good fit for account life cycle, could you please check with @timmy5685 .

@ismaeldcom Since you were looking into this issue earlier, do you know if @moon0326's #1527 (comment) about React components being unavailable on the Plugins page is still valid?

Hey @anu-rock, not sure about the mentioned limitations.

My idea back in the day was to create a new webpack entry, enqueue the script on the plugins page, adding a listener to the WooPayments deactivate link which will take care of mounting the React modal.

I'd encourage using Crowdsignal rather than MC. MC is difficult to parse data from and the above, while similar to other, is in need of modernization. Crowdsignal makes it very easy to get top level stats and to dig into the qualitative data. And we're able to tweak questions as needed without development.

The Shopper Experience team is happy to lend capacity for this must have feature. We've added this churn survey for WooPay and we get excellent participation and easy to view data. The CSS could be improved a bit for font and styling. Overall it's working great.

The existing design imo makes it way too easy to select the red, provide no feedback option. The above Crowdsignal example with only a single button, a constraint of Crowdsignal, works in our favor to make answering the survey the more natural path.

@pierorocca Wow, thanks for the tip. It looks pretty nice.

@mordeth Maybe there's an opportunity to lift and shift the exit survey component from the WooPay codebase?

@alefesouza added code so that if a merchant toggles WooPay on and off, the survey will show only after 7 days has passed since the last participation. Helps to not spam the merchant and to not have duplicate survey data.

@elizaan36 What are your thoughts on utilizing a Crowdsignal form instead of linking to an external survey? I believe it would facilitate gathering more feedback. After conducting some investigation, it seems that implementing it would require a similar level of effort.

hey @mordeth I think it's a great approach! Let me know how I can support.

Thanks for all the input here @pierorocca. Sounds like we're all in agreement to use this.

@anu-rock i'm in favor of moving forward with this.

@elizaan36 - any issues with the 7 day delay that Shopper Experience used? I think it makes sense.

If you all need support, @alefesouza will be able to spend a few hours next sprint assisting. Super excited to start collecting this data.

@elizaan36 - any issues with the 7 day delay that Shopper Experience used? I think it makes sense.

@timmy5685 I don't think implementing a delay would be feasible in this scenario. The survey we're seeking is triggered upon deactivating WooPayments, and we need to display the survey immediately after the Deactivate button is clicked. Once the WooPayments plugin is deactivated, we won't be able to display it anymore.

Should be OK since unlike a feature it's unlikely the gateway will be toggled on and off excessively.

Late comment but I think it's highly possible for the user to toggle the gateway on and off during testing, so the 7 day delay is a good idea.

@timmy5685 I don't think implementing a delay would be feasible in this scenario. The survey we're seeking is triggered upon deactivating WooPayments, and we need to display the survey immediately after the Deactivate button is clicked. Once the WooPayments plugin is deactivated, we won't be able to display it anymore.

@mordeth Can we save the deactivation time stamp in memory so the survey isn't triggered again for that store within 7 days timeframe?

@elizaan36 Could you elaborate more on your proposal for the 7-day delay? Disabling the WooPayments plugin differs from disabling a WooPay gateway because when a merchant disables the plugin, we lose the ability to execute any actions.

I think the thinking here is:

1. Merchant installs and activates WooPaymenrts
2. On Merchant deactivating, but not uninstalling WooPayments, persist deactivation date in WooPayments or Options table
3. Display Survey
4. Merchant re-activates WooPayments
5. Merchant again deactivates WooPayments. Triggering on this action, check last deactivation date in table. If < 7 days, show survey.

Is that doable?

Absolutely, that's a very valid point and doable! However, adopting that approach might result in missing out on valuable feedback from merchants who used and deactivate the plugin and never reactivate it, which could be more beneficial for our needs.

I think that's where the x days strikes the balance between capturing the data but not spamming the merchant and not collecting the same data twice.

With the current implementation, the survey would appear only once during the initial deactivation and would not be displayed again. This ensures that we don't overwhelm the merchant with repeated requests for feedback and avoid collecting duplicate data.

Both approaches have their advantages and disadvantages, so we need to choose the one that would yield the most valuable feedback. In my opinion, opting for the one-time immediate request would be a better approach, considering that merchants typically don't deactivate and reactivate WooPayments frequently during configuration.

We could test out the 7-day approach and assess its effectiveness in gathering valuable feedback. If it doesn't yield the desired results, we can always remove the delay. WDYT? cc. @pierorocca @elizaan36

With the current implementation, the survey would appear only once during the initial deactivation and would not be displayed again. This ensures that we don't overwhelm the merchant with repeated requests for feedback and avoid collecting duplicate data.

Gotcha! I had assumed that the survey would appear upon every deactivation. If it appears only once during the initial deactivation that's reasonable, however thinking of the use case where merchants/builders are testing the gateway on and off, the 7 day delay would be a better option. That way we can understand the long term usage after the testing phase.

We could test out the 7-day approach and assess its effectiveness in gathering valuable feedback. If it doesn't yield the desired results, we can always remove the delay. WDYT?

I think this is a good approach. Thanks @mordeth!