Wp-calypso: Gutenboarding: don't suggest taken domain

[simison]

Searching for "s" suggests "s.com":

Searching for "demo" suggests "demo.cloud":

[simison]

In progress p1586444583486200-slack-cobalt cc @klimeryk

[klimeryk]

I think regardless of the outcome of the discussion with our third-party suggestion provider, you _must_ do an additional availability check, period (same as the current domain suggestion flow). It is impossible to build a performant suggestion engine with 100% accuracy due to the wonderful and chaotic world of domain registries (and how they love to _not_ share their data).
Fixing the bug will decrease the number of these false positives, but it's impossible to eliminate them and there has to be an additional check for availability before you can be sure the domain can be purchased by the user. Otherwise you risk a very poor UX where the user lands in checkout and it immediately removes the domain. That's because shopping cart also double-checks the domain's availability - someone else could register the domain in the meantime (we've seen that happen - for various reasons, including the same user being confused and creating two accounts and doing the same thing on them).

[simison]

@klimeryk should the check happen before we show the list, during showing that list, at the moment customer picks a domain, or just before we attempt to create the site with that domain?

Or all of that. 😀

[klimeryk]

Hahah, thankfully not all of that. Sorry for not making it clearer before. The availability check should happen in two cases on the domain search:

The moment customer picks a domain - basically you have to assume that the suggestion endpoint is not always 100% accurate and might return unavailable domains. So, once a domain is selected, you should for it's availability via the is-available endpoint.
You can see it in action in the current domain search - at first I select a suggestion that turns out to unavailable and then one that's available and I'm allowed to proceed.

https://cloudup.com/c0yynmBzeud

The other moment is when the user explicitly searches for a FQDN, including a subdomain. That means they have a specific domain in mind and we should show its availability. If it's available, we should be sure to communicate that to the user - currently we simply insert it as the first search result:

(since the user _might_ be interested in other suggestions, which might be more attractive)

But if the domain is unavailable, we should guide them on what are their options. For example, this domain is registered, but the user can transfer it in:

There's a bunch of statuses to handle here and don't even get me started on subdomains 😅 Unfortunately, if we don't do it, users contact support confused or angry that we don't support their domains or they don't know how to get them on our platform. Most of the cases handled here (domain taken but transferable/mappable, domain available but cannot be registered, etc.) have been based on feedback from HEs and users and skipping them could lead to missed opportunities to sell domains and increased support load. Have a look at this file for some of the supported states: https://github.com/Automattic/wp-calypso/blob/f2c9d99b07e14ea938829e9b2e5b31b6fb388a90/client/lib/domains/registration/availability-messages.js

[simison]

Thanks for elaborating @klimeryk ! I split these as tasks to issues:
https://github.com/Automattic/wp-calypso/issues/41219
https://github.com/Automattic/wp-calypso/issues/41220