Wp-calypso: Domains: Adding .de, .ca, .fr ccTLDS

[mikeshelton1503]

We will be adding .de, .ca, and .fr ccTLDS to our domain offerings. Each of those comes with certain country specific requirements in addition to the basic domain contact information we already collect.

I've outlined below how we can include each of the requirements while minimizing impact on the domain contact form and trying to maximize conversion for ccTLD registrations.

For any requirements that require additional fields we will add a step after the domain contact form:

• Note the button copy on the domain contact form changes to "Continue".

• [ ] .ca

• [x] .de

• [x] .fr

.fr

_Requirements:_

• privacy must always be OFF
• Individuals:
  -collect DOB
  -collect Country of Birth
  -collect Place of Birth (if ^^ France)
  -collect Postal Code of Birth (if ^^ France)
• Companies/Organizations:
  -all the above plus:
  -VAT Number (optional, but rec’d)
  -(EU) Trademark Number (optional, but rec’d)
  -SIREN/SIRET Number (optional, but rec’d)

Add step for additional fields (note: all fields shown in screenshot):

Display a notice on the domain contact info page that informs the registrant that their contact info will be public:

.ca

_Requirements_

• Privacy must always be ON
• Registrant must agree to CIRA agreement
• Collect CIRA presence identity

On the domain contact info step we should just not display privacy protection since it'll be on (though we will need to be sure not to charge for it). No need to inform the user of this, they would likely assume their info isn't be shared publicly.

.de

_Requirements_

• privacy must always be OFF
• Country must be Germany

If a country other than Germany is selected, display an error message:

cc @ranh @breezyskies for design and copy review
cc @deBhal @hewsut for technical review

[breezyskies]

This is looking great @mikeshelton1503! One quick question on:

On the domain contact info step we should just not display privacy protection since it'll be on (though we will need to be sure not to charge for it).

I believe this was mentioned at some point, but how would this work in the case the user had multiple domains (different TLDs) in the cart? It seems edge case, since most of our flows are optimized for the single-domain purchase, but just curious. (Note: We could potentially deprioritize this scenario for now by focusing on NUX and Tortuga, which only _allow_ single domains purchases at the moment.)

No need to inform the user of this, they would likely assume their info isn't be shared publicly.

In generally I agree, but there's also the question of "well, then why do you need this?" I think some microcopy couldn't hurt here, similar to what we did on Delphin.

[hewsut]

Companies/Organizations:
-all the above plus:

Are we sure on that for fr? I'm having trouble determining for _certain_.

[deBhal]

The OpenSRS Docs for the extra infor say that the "Individual" fields are all required only for individuals, and that even the company fields are only "Optional, but recommended".

[deBhal]

@mikeshelton1503 - How do you see the optional fields for the FR working?

The Individual/Organization fields are an either/or, so I think toggling the checkbox is going to change what fields you can see?

What about the fields that are only for Individuals born in France - should we hide them or disable them for individuals from other countries?

Do you think we need copy explaining that there are different requirements for Companies/Individual/People born in France?

Edit: Forgot to say: Looks great!

[deBhal]

Turns out date pickers are more complicated than I would have thought.

I think we should go with a text field for Year. We could get away with the design as-is, given this is a particularly French component (I'm shocked that YYYY/MM/DD isn't universal, but I really shouldn't be by now :/), but there's some research indicating text is better for Year in particular for DOB (ux.stackexchange), and I think we should go that way.

There's a third combined text/date-picker option, like: http://react-day-picker.js.org/examples/?simpleInput . That's using the react-day-picker that our existing date-picker (devdocs/date-picker) is built on, but even so the uncertainty makes me lean away from that approach.

[mikeshelton1503]

Sorry, I completely forgot to include my plans for the interactions!

How do you see the optional fields for the FR working? The Individual/Organization fields are an either/or, so I think toggling the checkbox is going to change what fields you can see?

Yes, this is the intent. We'll hide and show the appropriate fields based on that question as well as the Country of Birth field for the other two birth fields.

For the individual/organization radios, one idea I have for reducing the need to change this field is to pre-populate it based on whether the "organization name" field from the domain contact info form was filled out. This way there correct fields should already be displayed when the page loads, but it can be changed just in case.

Do you think we need copy explaining that there are different requirements for Companies/Individual/People born in France?

No I don't think it'll be necessary. I think it's implied by seeing the fields change. Once we get it in there, if it's not quite working I can add a subtle transition animation as the fields switch out.

[deBhal]

pre-populate it based on whether the "organization name" field from the domain contact info form was filled out.

Great idea.

I think it's implied by seeing the fields change.

👍

[mikeshelton1503]

I think we should go with a text field for Year. We could get away with the design as-is, given this is a particularly French component (I'm shocked that YYYY/MM/DD (isn't universal )[https://en.wikipedia.org/wiki/Date_format_by_country], but I really shouldn't be by now), but there some research indicating text is better for Year in particular for DOB (ux.stackexchange), and I think we should go that way.

I'm ok with that, though In that case I'd rather be consistent and use text fields for all 3. I debated on them in the first place but opted for selects so the user wouldn't have to worry about format so much.

[deBhal]

I'd rather be consistent and use text fields for all 3

Sure thing :)

[mikeshelton1503]

how would this work in the case the user had multiple domains (different TLDs) in the cart? It seems edge case, since most of our flows are optimized for the single-domain purchase, but just curious. (Note: We could potentially deprioritize this scenario for now by focusing on NUX and Tortuga, which only allow single domains purchases at the moment.)

It was discussed that we wouldn't support multiple ccTLD purchases. However, I'm not sure exactly what that means because while we don't make multiple domain purchases obvious it is possible to do. @deBhal @hewsut What's the plan if a user tries to add a second ccTLD domain?

In generally I agree, but there's also the question of "well, then why do you need this?" I think some microcopy couldn't hurt here, similar to what we did on Delphin.

@breezyskies I agree. Though wouldn't this be a change to the domain contact info form page itself, for all domains? Even with Privacy Protection there we don't really explain why we're collecting it very clearly or at least the explanation is buried in with Privacy Protection rather than a general explanation for the page. I think we should still do it though, as you said, similar to get.blog.

[deBhal]

The plan in the lead at the moment is to fail if we detect incompatible ccTLDs, and make the user enter the details for each domain individually, with some pre-filling support.

[ranh]

General note about copy, we should avoid any negative associations with these policies, for example with phrases like "we are required".

For users new to domains, our existing contact information screen is already a major obstacle, and we make no apologies about that (indeed, we make no explanations about it at all). This keeps the flow quick and casual. Let's try to do the same here.

Almost done! In order to complete your registration, we're required to collect some additional information.

This message can simply be removed. As is, it only makes the flow seem more complicated. It doesn't actually explain why people have to give this information, or how it will be used.

Privacy notice: When registering a .fr domain it's required that your contact information be displayed in a public database.

Let's change this to: "Your contact information will be available in a public database of all .fr domains" (based loosely on #12622).

PS, does this apply to anything entered on the next screen too?

To register a .de domain, your address is required to be in Germany.

Let's change this to ".de domains can only be registered with an address in Germany".

I noticed that GoDaddy offers to let users use a proxy service. Can we do the same?

---

For any requirements that require additional fields we will add a step after the domain contact form

Why? I understood this to be intended as a way for us to avoid making changes to the current contact screen. But if we're changing that screen anyway, why also add another one?

An extra step may make sense for .fr, since there is a lot of extra detail to fill in. But even then, I would suggest experimenting with a different grouping of fields over the two screens.

It doesn't seem necessary for .ca, which would only add one field and one checkbox.

[mikeshelton1503]

For users new to domains, our existing contact information screen is already a major obstacle, and we make no apologies about that (indeed, we make no explanations about it at all). This keeps the flow quick and casual. Let's try to do the same here.

I disagree. I'm not sure "no explanations about it at all" equals "quick and casual". I agree we have to be careful what we do say and should be succinct with it.

Why? I understood this to be intended as a way for us to avoid making changes to the current contact screen. But if we're changing that screen anyway, why also add another one?

@ranh What do you mean "If we're changing that screen anyways?" Yes we are making a couple small changes for .de but those are barely noticeable.

It doesn't seem necessary for .ca, which would only add one field and one checkbox.

If we were only adding .ca and not ever adding anymore I might agree, however the second screen is meant to be a repeatable solution as we add more and more ccTLDs later. Yes, we could add .ca questions to the contact form, however 1) it does add length to the form, even if not a lot, and 2) as a solution for all ccTLDs I'd rather not say "well if there's a only a couple fields we can slap them onto the domain contact form". I prefer to have a consistent, repeatable solution. (.de is an outlier because it's requirements are tied to existing fields on the domain contact info form)

[deBhal]

Almost done! In order to complete your registration, we're required to collect some additional information.

This message can simply be removed. As is, it only makes the flow seem more complicated. It doesn't actually explain why people have to give this information, or how it will be used.

One other thing we might want to consider is a link to our support pages. We haven't written them yet, but we will want documentation for users, and some sort of statement here would be a natural place for that link.

But even then, I would suggest experimenting with a different grouping of fields over the two screens.

@ranh I'd like to get something in place, and push UI experiments out into a separate PR, but if you could spitball some examples of the sorts of splits you're talking about, I can keep that in mind while I'm working on related tasks.

I noticed that GoDaddy offers to let users use a proxy service. Can we do the same?

Yeah, that's a good question. It's not on the plan right now (it doesn't make much sense until we offer domains that need it), but is definitely something to look into. I wonder if we should add a "more information" link and track it to gauge interest.

@mikeshelton1503 Just occurred to me: What about a back button?

[ranh]

as a solution for all ccTLDs I'd rather not say "well if there's a only a couple fields we can slap them onto the domain contact form". I prefer to have a consistent, repeatable solution

There's a constant tension in this project between reducing overhead and improving the experience. But overall it looks like we're leaning towards optimizing for engagement rather than reducing the work required to launch.

With that in mind, I think it's a mistake to think of all ccTLDs as a uniform group of similar objects. I don't think we need a consistent repeatable solution, especially when we don't even know how many times we would have to repeat it, or whether we'll repeat it at all. I think we would be better off thinking of each ccTLD as a unique product with unique requirements and targeting a unique audience. That would help us better understand the requirements and design a better experience.

I don't know if there's any need to redo this work or redesign this with a different main contact form. Just adding my two cents about the general approach.

[yoavf]

Closing this: all registration flows have been implemented. Thanks to everyone involved!