Domains: Move "Make Primary" to domains list

[mikeshelton1503]

Background

I'm proposing a new flow for changing the primary domain of a site. There are two main factors contributing to the need for this new flow:

• Currently, when you click "Make Primary", a confirmation screen is shown. It serves no other purpose than to confirm the action taken and communicate relevant information about the action.
• The "Make Primary" button receives roughly 18,000 clicks per month, much more than anticipated.

After evaluating the content that is currently on the "Make Primary" screen, what actually needs to be said boils down to this:

• What is a primary domain?
• The current primary domain is _______.
• All domains redirect to primary.

New Flow

The proposed flow here removes the need for explicit confirmation messaging by changing the context in which the "Make Primary" action is performed and providing an easy method in which to "undo" the change.

See it in action: https://cloudup.com/c1BYft3TgEz
*Note: The animation for the spinner is not accurate it's just there to show that a loader will be used.

This follows a similar pattern used in Plugins for bulk edit.

Undo action

The undo action is essential to this flow. Since the explicit confirmation screen has been removed we need to be sure the action affirmation is noticed and that the ability to undo is clear.

Loading state
I debated whether to include a loading state/spinner, however the current performance of the Make Primary action takes a few seconds. If we can improve that and make it instantaneous that would be preferred and would eliminate the need for a spinner.

Another option to consider: if the time to complete the action can't be improved (or guaranteed) we could show the action as performed instantly in the UI, even if in the background it's processing. This suggestion is based on the assumption that the action is always successful (meaning the chance of the action not succeeding within a reasonable amount of time is very low). Not sure the feasibility here though.

cc @breezyskies @danhauk

[umurkontaci]

I debated whether to include a loading state/spinner, however the current performance of the Make Primary action takes a few seconds. If we can improve that and make it instantaneous that would be preferred and would eliminate the need for a spinner.

Unfortunately, we won't be able to make it shorter since changing primary URL changes the URL structure, and we need to be wait for the server's response and sites update to do conflict resolution.

For the same reason, we also don't want the user to be navigating around while this action is being processed since the URL structure will change the user the links will be broken.

We were able to minimize this impact by making an explicit page change and holding the user there; I will see what can be done to improve the situation

[umurkontaci]

@mikeshelton1503 One thing we might need to take into consideration is how many users click "Make Primary" button more than once. I'd assume that they would change it once they buy a domain and never touch it again.

If that's the case, it might make sense to keep the confirmation screen in place because it feels like chances of a user changing it by mistake gets higher. I know that we do have an undo button, but that (I think) mostly fixes "accidental" clicks, if you don't know the total impacts of the change you've just made, you wouldn't click undo.

[klimeryk]

I agree with Umur, but maybe just improving the message in the success notice could be enough? Someting like "Primary domain changed - all domains will redirect to example.com and this the domain visitors will [only] see [from now on]". Because the "domain visitors will see" seems the most important part to the user (at least that's what I remember from my support rotation).

[mikeshelton1503]

we also don't want the user to be navigating around while this action is being processed since the URL structure will change the user the links will be broken

Ah interesting. I think we'll be ok though because with the spinner, we are showing that an action is being processed. So 1) that should deter some users from navigating until it's done and 2) if a user does try to navigate away we could perhaps show a message that tells them that an action is processing and give them the option to leave anyways or let the action finish. (I'm not in love with that but it could work).

One thing we might need to take into consideration is how many users click "Make Primary" button more than once. I'd assume that they would change it once they buy a domain and never touch it again.
If that's the case, it might make sense to keep the confirmation screen in place because it feels like chances of a user changing it by mistake gets higher.

That is very well possible but I think the thing to focus on here is what's the consequence of a user changing it by mistake so long as we make it clear what the change did and provide an easy way to undo? I don't think the risk is high here but I do agree with:

if you don't know the total impacts of the change you've just made, you wouldn't click undo.

This is true but 1) this can be improved. I agree with @klimeryk that the copy for the message could be a little clearer and use language that's more familiar to the user. And 2) it's not a destructive action so worst case scenario if the user accidentally changes it and doesn't realize what they did until later it can still be "undone" even after the "undo" action disappears. To be clear I'm not saying that last point is ideal just that in the case (that I expect to be very rare) that everything else failed, the action is not irreversible. Of course this would be something we would monitor to ensure it's not a common case.

[umurkontaci]

it's not a destructive action so worst case scenario if the user accidentally changes it and doesn't realize what they did until later it can still be "undone" even after the "undo" action disappears

Not totally destructive, but I personally wouldn't want my primary domain to change by mistake even though I can undo or manually set it back. I guess I have the perception that things that cause big changes need to be confirmed. Especially on mobile this is a problem where the devices are very likely to confuse a scroll intent with a click. That said, I could be biased and would trust your judgment.

To be clear I'm not saying that last point is ideal just that in the case (that I expect to be very rare) that everything else failed, the action is not irreversible. Of course this would be something we would monitor to ensure it's not a common case.

👍 monitoring. I think we should start monitoring (if not already) of all the undo clicks throughout Calypso, it will give us a good idea on where we stand.

[mikeshelton1503]

That said, I could be biased and would trust your judgment.

I always reserve the right to be completely wrong 😄. I think that the benefits (reduced complexity) are worthwhile to test it out. What I meant by the "worst-case scenario" was that in the event that I'm completely wrong, the damage is not irreparable prior to us reverting or iterating further. The monitoring will play an important role here. If we have a high number of "undos" or influx of tickets we can iterate.

I have the perception that things that cause big changes need to be confirmed.

This idea is in part what I want to challenge with this change. My gut is that this feeling is overly precautionary (though not unjust or uncommon). If we can disprove this thought we can start to apply this concept elsewhere.

[umurkontaci]

Well I'm convinced :) I'll spend some time to discover what can we do about the URL structure thing.

[davewhitley]

Just looked at the video. I think that having a message after you Undo would be more clear. The user would be more confident in what just happened.

[davewhitley]

Ah, never mind, I see the undo message in the PR.