Delete Site: Redesign the site deletion workflow

[bummytime]

Discussion from Mobile Requests:

We get quite a few requests from people who delete their sites then want them back. Many who come back say they did it by accident. Or they want to use their domain elsewhere and don’t understand that they won’t be able to use that domain again. Even though we do warn them:

Can we make that “(sitename) will be unavailable in the future” a pop-up and/or make the verbiage a bit more clear? (ex: If you delete this site, you will not be able to use this domain again in the future.)

Also, ref: #6946

[bummytime]

Design idea from @folletto:

So I think that limited to the mobile app, we could make sure the operation is communicated as clearly as possible.

In that scenario, I’d consider maybe a design that breaks the screen in multiple steps, and for each step the person has to tap “Delete X”. This would make more easy for people to digest information (as it won’t be a blob of text).

The steps could be:

• Delete Site — “Deleting the site will remove all content, contributors, domains and upgrades from the site. Are you sure to continue?” [ Continue ]

• Confirmation 1/3: Content — “Deleting the site will erase forever all the data, with no possibility to get it back. If you haven’t done it already, consider exporting the content before deleting it. Are you sure to continue?” [ Yes, delete content forever ]

• Confirmation 2/3: Upgrades — “Deleting the site will remove all your paid upgrades, with no ability to transfer it. Make sure you’re ok in losing these upgrades. Are you sure to continue?” [ Yes, delete the subscriptions ]

• Confirmation 3/3: Domain — “Deleting the site will remove the address $name forever, and you won’t be able to use it anymore. If you clear the site instead of deleting it you will be deleting its content but keeping the name. Are you sure to continue?” [ Yes, delete everything ]

• In Progress… — This should be delayed by 3-5 seconds, and for these 3-5 seconds there should be a “Cancel” button. Then, it gets hidden/disabled and the process kicks off.

Each of these screens contain an alternative too: export, review upgrades, empty sites, all with links to the specific page to do that action.

[wensco]

Delete Site — “Deleting the site will remove all content, contributors, domains and upgrades from the site. Are you sure to continue?” [ Continue ]
Confirmation 2/3: Upgrades — “Deleting the site will remove all your paid upgrades, with no ability to transfer it. Make sure you’re ok in losing these upgrades. Are you sure to continue?” [ Yes, delete the subscriptions ]

We need to be careful about this when the upgrade in question is a custom domain.

I would be much more comfortable if we required the user to first cancel their domain before they can delete the site. From a compliance perspective, that makes it totally clear that the user intended to cancel the domain (as an option, they can also transfer it away). Also, removing the subscriptions does not actually cancel/delete the domain and can lead to the user getting renewal notices and other things down the line.

[folletto]

I would be much more comfortable if we required the user to first cancel their domain before they can delete the site.

That's a good idea. The multi-step process could just not be able to start until the user manually removed all the upgrades / domains in the other screens.

In that case we could move the "upgrades" step first, and instead of just a confirmation we won't allow the user to proceed unless everything is removed. We just provide a link to the screen where they can be removed... which I think on mobile they don't exist tho? So it has to be via web?

[wensco]

The multi-step process could just not be able to start until the user manually removed all the upgrades / domains in the other screens

I like this approach. Given that the issue was created over a relatively high volume of people who delete their entire site, despite the warnings that it’s permanent, and then later say "oops I didn't realize that permanently deleted my site", I suspect that most of them using the current flow also don't realize they are losing their domain in the process.

It would be good to consider adopting something similar to the web-based Calypso flow (#) for mobile users. At minimum it would be good to have them specifically cancel or transfer away at least their domain as a separate action as a pre-req to deleting their site. I'm no expert on IOS/mobile flows, so I can't comment as to whether that's an available option in the IOS app or not. We'll need to make the same adjustments in the Android mobile app as well.

As long as we require them to cancel their domain (and possibly other paid upgrades) before initiating site deletion, this copy is moot but I wanted to mention it just in case. If we don't require users to explicitly cancel their domain before starting the site deletion flow, we would need to adjust this copy:

Confirmation 2/3: Upgrades — “Deleting the site will remove all your paid upgrades, with no ability to transfer it. Make sure you’re ok in losing these upgrades. Are you sure to continue?” [ Yes, delete the subscriptions ]

Users do have the ability to transfer their domain to a different wpcom user or a different registrar. We can't prevent them from transferring their domain, except under a very limited and particular set of exceptions. While we're not absolutely preventing them from transferring if they drop out of the site deletion flow and go to /purchases, that option is hidden in the current flow. This copy tells them they can't transfer, which implies that we are preventing it so we would need to change that.

Thanks for hearing me out with all of the pesky compliance and other issues related to domains. :) Going forward, Cobalt team is happy to help however we can, from a technical or compliance point of view regarding custom domains - even if it's just to run an idea by us or make sure there are no hidden compliance gotchas in a proposed flow.

[folletto]

One thing is something I'd add: I understand it's a lot of work, but would be ideal if any change could be applied across all our systems.

I wouldn't be against in this specific instance to create a "headeless" (i.e. no masterbar) version of the web flow that we can just load in a WebView on mobile, thus making any update and any maintenance a "one point" change.

These screens can tolerate being slow in terms of performance, so I feel it would be something we should discuss.

[daniloercoli]

I wouldn't be against in this specific instance to create a "headeless" (i.e. no masterbar) version of the web flow that we can just load in a WebView on mobile, thus making any update and any maintenance a "one point" change.

💯