Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Email Verification: Improve the UI of the Pending Email Change banner #94247

Open
javierarce opened this issue Sep 5, 2024 · 3 comments
Open
Assignees

Comments

@javierarce
Copy link

javierarce commented Sep 5, 2024

Related to #93895

When a user with an unverified email address changes it, we currently display two notifications stacked on top of each other, which creates a confusing experience for the user.

image

We are addressing the placement of the notification on top in #93895. This issue focuses on the one at the bottom, the pending email change banner.

The proposal is to replace the second notification and use the line under the email field to offer users the option to update their address.

image

Clicking on the link will enable the input field so they can modify the email:

image

Once the user submits the form, we display a floating notification to inform them that we have sent a verification request to their email account:

image

This way, we'll also make cancel functionality we offer in the curent banner more transparent for the user.

Link to the designs: wCm5Tzb7JBaG4WNowWbjES-fi-4978_968

@Addison-Stavlo Addison-Stavlo self-assigned this Sep 17, 2024
@Addison-Stavlo
Copy link
Contributor

@javierarce - This second notice has another variation with some extra format and copy in the case of having a custom domain registration:

Screenshot 2024-09-18 at 2 03 32 PM

Should we add an extra line in the copy under the input in this case? Or other thoughts?

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Sep 18, 2024

Another clarification Q in addition to the above @javierarce : The banner component currently displays interface color (--color-accent). It seems like we are kind of using it as a warning notice instead. Should we override it to be red like in your design (or is that actually your accent color?) ?

Screenshot 2024-09-18 at 4 18 28 PM

Im assuming we may want it to be red given this context regardless of interface colors, but figured I would confirm.

Q: Also note in the copies in the banner images your added above there is a grammatical error around "your email help you secure". Should this be "your email helps you secure" or "your email will help you secure" ?

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Sep 20, 2024

@javierarce for when you are back. I have 2 separate items to consider for you.

Item 1 - Explanation copies

Related to my comment two comments above this, I tried to adjust the explanation copy to accommodate these extra cases within the pending email change cases:

  1. If the user has a custom domain, there is extra information given about needing to update the email for those registrations as well.
  2. It wasn't clear (to me) by the original notice, but the "cancel" button actually is set up to cancel the pending email change (go back to the verified email), and unlock the input. I added a a section of the explanation to show a button to cancel the pending email change in the case that there is an email change pending. I also think this could allow us to simplify a bit (more details about this in item 2 below).

Ive done my best to fit these extra cases and contexts into the explanation text shown. These are how I have currently setup those cases in the PR ( I imagine we might want to adjust, consolidate, remove - but I wanted to first highlight the functionality that is in place before ripping it out):

Pending email change (no domains):
Screenshot 2024-09-20 at 2 55 00 PM

Pending email change (with domains):
Screenshot 2024-09-20 at 2 56 45 PM

Email not verified:
Screenshot 2024-09-20 at 2 57 36 PM

General case:
Screenshot 2024-09-20 at 2 57 53 PM

Item 2 - Simplification - don't change disabled input behavior and lean on the cancel functionality.

After looking into all this there is one proposal I would like to make, as this seems like it is starting to feel more complicated than necessary on the code side (and maybe the UX side?) in order to enable unlocking and editing during pending changes, etc.

My proposal is that we continue to use the existing behavior for when the input is unlocked vs. locked.

  • No pending email change: input is enabled.
  • Pending email change: input is disabled.

So for when there is a pending change instead of us having a link to "click here to update it" to enable the input, we instead lean on a link to "click here to cancel the pending email change" (which in turn does revert the pending email change and unlocks the input). It seems subtle, but I think this would simplify the behavior a lot, as well as the code and the copies shown.

New copies could then be along the lines of:

  • Pending email change (no domains):
    "Your new email has not been verified yet. To cancel the pending email change click here.
    Update contact information on your domain names if necessary here."

  • Pending email change (with domains):
    "Your new email has not been verified yet. To cancel the pending email change click here."

  • Email not verified:
    "Your email has not been verified yet."

  • General case:
    "Not publicly displayed, except to owners of sites you subscribe to."

Thoughts? This PR is currently in the unsimplified form if you would like to test the calypso live link, but Im starting to think we may want to simplify that lock/unlock behavior back to whether or not there is a pending change. I didn't realize that previous 'cancel' button on the notice reverted the pending email change and unlocked the input, and Im thinking if we just made that functionality more clear we wouldn't really have any need for an extra 'unlock' the input button.

EDIT - Another PR (2) I quickly threw together to outline my simplified proposal to help make it more clear. What I am saying may make more sense being able to test it on calypso live.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants