Signup: Show exact match unavailable TLDs in the results list

[apeatling]

Please watch the "Choosing and Selecting a Domain" testing video on this post: p58i-8d4-p2

• “This is where I was very confused yesterday”: He wanted erhanerdem.com but it does not show up for him when searching his name. This is because it’s already registered. “It would be nice if it was shown here that it was taken”.

---

It would be ideal to show exact match domains as "unavailable" in the domain list so there is no confusion here. The user clearly did not understand why he could not select his name.

via @michaeldcain: "There's already a second API call made to filter out taken domains from the initial response. I wonder if we can just update it to mark those domains as taken."

[klimeryk]

@apeatling What's the context of this (and the other one's you've created: https://github.com/Automattic/wp-calypso/issues/37266 https://github.com/Automattic/wp-calypso/issues/37268 https://github.com/Automattic/wp-calypso/issues/37276 https://github.com/Automattic/wp-calypso/issues/37278 https://github.com/Automattic/wp-calypso/issues/37277) issue? Without descriptions, these are pretty vague.

[apeatling]

I'm stubbing them out and will be filling in the descriptions shortly.

[apeatling]

@klimeryk I've filled in all the domains issues. What's the best way to triage them and figure out where they might sit priority wise?

[jd-alexander]

Hey everyone!

The timing of this user testing video is spot on for us (WordPress Android team). We were looking into this very issue recently as part of our Site Creation improvements.

We got to a point where we were creating the logic to do this verification on the client-side but then realized it would be better if this is all done on the server so that there can be shared behavior across platforms. We didn't opt for the server at first because our investigation showed two separate endpoints being needed to get the domain's availability /domains/$domain/is-available and suggests /domains/suggestions and on the mobile side of things it's all about performance and reliability in the most adverse situations; we are trying to ensure that there aren't multiple points of failure which would lead to more difficult error handling and UI/UX scenarios.

So we are wondering what approaches would be considered for this to be support on all platforms.

For us, these are the ideas we have are as follows :

Optimal

A query param gets added to the /domains/suggestions endpoint so that it also returns a domain availability object of some sort that would allow us to determine the availability of the domain and if it's invalid or not since users are able to enter a domain that might not match the constraints in place for them. This would allow full backward compatibility support and we would be using only one API endpoint.

Alternative # 1

We mimic the client-side behavior that's being done in Calypso, so whichever strategies are used to validate domains & update the UI we mimic that for the mobile clients.

Alternative # 2

A new endpoint is created that will provide the domain's state and the suggestions.

Let us know your thoughts. In any case, we are more than happy to assist with any proposals or ideation that's needed to get this moving as we are very committed to making the Site Creation process smooth for our users 😄

[kelliepeterson]

@apeatling @klimeryk

If I'm circled in and/or pinged (as happened toward the end of this testing session) I can take the learnings back and drop them onto Cobalt's backlog. We discussed this, but I just realized that I didn't actually create a task for it, so thank you for making sure it got documented. We used to show a taken name if the customer entered a fully qualified domain name, but that was changed during the Kracken project.

In an ideal world, anything on the actual search results page doesn't get worked on until Cobalt is looped in. Often it's just a courtesy so that we can act as traffic cops to make sure that no work is done at cross-purposes or simply doing double work. In other cases, we can actually save engineering time by acting as SMEs. Finally, there are a few things we would need to dissuade folks from doing for either compliance or contractual reasons.

[kelliepeterson]

Follow up - I just remembered that he entered words, not a FQDN. We would be assuming that he wanted a .com (reasonable assumption in the US, but unreasonable elsewhere).

Currently if a user enters a FQDN we ask if they own the domain and offer to map it.

It's not commercially beneficial to show a page filled with things we cannot sell or provide.

My personal feeling is that we're actually doing the right thing here for the widest array of users, but we can certainly tweak.

[apeatling]

Thanks @kelliepeterson. This is one issue I would say could use a few more user tests to see if there is a pattern.

In theory it does make sense, if I have never searched for the domain I want before and I don't know it's taken I would be confused as to why it doesn't show. I don't think we'd need to fill the screen with these -- even if we showed the next best match that could be purchased, with the exact domain name match next to it crossed through with an "unavailable" marker.

[kelliepeterson]

@apeatling That'd be great.

It totally makes sense - and that's actually what we do IF they type in a full domain name with an extension, but if they don't do that we can't tell them their "desired domain name" is not available" because we can't know what they actually desired.

Yes, in the US it's usually a .com, but it might also be a .org. Outside of the US it's very likely to be a ccTLD (of which we still have a long way to go to bring on new options - we're starting on this soon).

I'm not a fan of the notion that we make an assumption to any specific TLD, but I am certain that we can find ways to improve the prompt and the experience as a whole. I'm going to be following along closely to these to see what others experience and then we can take action when we have a bit more feedback.

I'm going to drop this into our Asana and close this out here. Re-open if you feel that's a mistake.

[klimeryk]

@jd-alexander happy to discuss options, but could we move the discussion to a P2? 🙏

[jd-alexander]

@klimeryk Sure! Sounds good.