Automattic
Connect Refresh: Migrate Gravatar & Grav-powered clients to unified Login (take 2)
Gravatar Fixes https://linear.app/a8c/issue/DOTCOM-13401/gravatar Fixes https://linear.app/a8c/issue/DOTCOM-13389/gravatar
WPJM Fixes https://linear.app/a8c/issue/DOTCOM-13402/wp-job-manager Fixes https://linear.app/a8c/issue/DOTCOM-13390/wp-job-manager
Proposed Changes
- Updates Gravatar and WP Job Manager Login screens to match the unified designs. These are handled together as they are both grav-powered clients. This is the second take, after https://github.com/Automattic/wp-calypso/pull/103883 was reverted due to affecting other screens in the flows ~and disabling the email-change skip functionality when user is already logged in~.
- The originals included a "Any question? Check our help docs." at the bottom. We reintroduce this for grav clients in the main Login screen.
| Before | After |
|---|---|
Why are these changes being made?
Gravatar Part of https://linear.app/a8c/issue/DOTCOM-13401/gravatar Part of https://linear.app/a8c/issue/DOTCOM-13389/gravatar
WPJM Part of https://linear.app/a8c/issue/DOTCOM-13402/wp-job-manager Part of https://linear.app/a8c/issue/DOTCOM-13390/wp-job-manager
Testing Instructions
- Got to Gravatar and confirm
- Go to WP Job Manager and confirm
- Go to any of the other client Logins from https://linear.app/a8c/issue/DOTCOM-13220/calypso-make-the-two-column-layout-and-unified-design-the-default and confirm no changes
Pre-merge Checklist
- [ ] Has the general commit checklist been followed? (PCYsg-hS-p2)
- [ ] Have you written new tests for your changes?
- [ ] Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
- [ ] Have you checked for TypeScript, React or other console errors?
- [ ] Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
- [ ] Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
- [ ] For UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
- [ ] For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?
Jetpack Cloud live (direct link)
|
|
https://calypso.live?image=registry.a8c.com/calypso/app:build-148022&env=jetpack |
Automattic for Agencies live (direct link)
|
|
https://calypso.live?image=registry.a8c.com/calypso/app:build-148022&env=a8c-for-agencies |
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:
App Entrypoints (~441 bytes removed 📉 [gzipped])
name parsed_size gzip_size
entry-login -1730 B (-0.1%) -441 B (-0.1%)
Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.
Sections (~79 bytes removed 📉 [gzipped])
name parsed_size gzip_size
jetpack-connect -448 B (-0.0%) -113 B (-0.0%)
stepper-user-step +102 B (+0.0%) +34 B (+0.0%)
accept-invite +102 B (+0.0%) +32 B (+0.0%)
Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.
Async-loaded Components (~113 bytes removed 📉 [gzipped])
name parsed_size gzip_size
async-load-design-blocks -448 B (-0.0%) -113 B (-0.0%)
async-load-signup-steps-user +102 B (+0.0%) +32 B (+0.0%)
React components that are loaded lazily, when a certain part of UI is displayed for the first time.
Legend
What is parsed and gzip size?
Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.
Generated by performance advisor bot at iscalypsofastyet.com.
@wellyshen here goes! Just a couple of notes:
- the unification project involves additional changes to go into these login screens. for example, a unified top bar with the WP logo in the left. Let's not jump into introducing another masterbar just yet. This is intented to be handled separately as part of "create your account" and "lost password" screen unifications. But if you can work out a way to reuse the same top bar and suggest the best way to change it, then more than happy to discuss.
- We will need to change the "Email me a login link" from the main content to adapt to Grav/Grav-powered clients (@evilluendas flagged this in https://github.com/Automattic/wp-calypso/pull/104036#issuecomment-2949409363)
Let's also please make sure I get to review code before shipping, as there are several refactors being worked on in parallel. One idea I'm shooting for is to bring everything behind isWhiteLogin and isSocialFirst (as this PR does), then remove these in one go to clean things up in the end. There will be a cleanup phase after everything migrates.
Thanks for helping! 👍
@wellyshen, also concerning the functionality of disabling the email field when a user is already logged in, as you explained here: https://github.com/Automattic/wp-calypso/pull/103883#issuecomment-2949433250
Can you please summarise or point to the discussions for introducing that to the Gravatar Login? Apologies if being naive, but I'd be curious why this doesn't happen for other clients and the default WP Login. Why does Gravatar need to diverge there, and should that become the default experience instead? cc @jasmussen / @matt-west
Can you please summarise or point to the discussions for introducing that to the Gravatar Login? Apologies if being naive, but I'd be curious why this doesn't happen for other clients and the default WP Login. Why does Gravatar need to diverge there, and should that become the default experience instead? cc @jasmussen / @matt-west
We provide the Gravatar Quick Editor SDK for both web and mobile. Developers can integrate the SDK into their apps so users can update their avatars and profiles. Because Gravatar is tied to email identity, the SDK needs the user’s email address. If we leave the email field enabled, users could sign in with an address different from the one they already use in the app, their updated avatar or profile won't be reflected in the app.
Because Gravatar is tied to email identity, the SDK needs the user’s email address. If we leave the email field enabled, users could sign in with an address different from the one they already use in the app, their updated avatar or profile won't be reflected in the app.
Thanks. If I understand correctly, the difference is between seeing their email typed into the username field and being editable vs not being editable? If this is correct, then a few additional questions:
- Does it happen often that a user would edit the email that's typed in?
- Since this functionality has been disabled/removed for some time, can we keep it that way i.e. not reintroduce it? Have we noticed any actual concerns with this functionality being absent?
Does it happen often that a user would edit the email that's typed in? Since this functionality has been disabled/removed for some time, can we keep it that way i.e. not reintroduce it? Have we noticed any actual concerns with this functionality being absent?
Most users sign in through the magic-code flow rather than the main login page. However, if disabling the email input field isn’t too much work, I’d like to add it back. Are there any concerns with doing so?
Does it happen often that a user would edit the email that's typed in? Since this functionality has been disabled/removed for some time, can we keep it that way i.e. not reintroduce it? Have we noticed any actual concerns with this functionality being absent?
Most users sign in through the magic-code flow rather than the main login page. However, if disabling the email input field isn’t too much work, I’d like to add it back. Are there any concerns with doing so?
Yes, I think a couple of concerns.
Maintenance one. We've already seen it disabled and going unnoticed, now propping into other context (here), causing additional headaches. This looks like a case where it's both hard to maintain and to keep track of. Why did it go unnoticed and product folks only finding out now? (etc)
Consistency with our core product, two (and more importantly). I'd prefer if diversions from core experience are for incedingly important and critical reasons. This doesn't seem like one. It's technically proven not to be one, from the looks of it?
Let me know your thoughts. FWIW I think my vote sould be to not bring it back.
Thank you for sharing your concerns with us.
Many users still sign in with an email address and password. Leaving the email field enabled could cause the problems I mentioned earlier. AFAIK, the maintenance required to disable it is minimal, so I recommend we do so to prevent those issues. After all, our creed reminds us: “I will build our business sustainably through passionate and loyal customers”.
If we leave the email field enabled, users could sign in with an address different from the one they already use in the app, their updated avatar or profile won't be reflected in the app.
https://github.com/user-attachments/assets/7383addf-74da-4dc9-bead-75ce4bd482a4
Thanks for your following up. I am concerned that this has not been active for an unknown amount of time, no issue reported in the meantime, and today product team quickly jumped the gun to revert work that didn't even cause the breakage, while seemingly magnifying the severity of this issue. This seems rather concerning?
Leaving the email field enabled could cause the problems I mentioned earlier.
Has it ever actually caused problems, as in have we measured this issue or reacted to a regular event happening? Or is this more along the lines of "in case it happens"?
AFAIK, the maintenance required to disable it is minimal
I don't think I agree. Maintenance failed to maintain the state of this. The goal of the unification is at least partly to avoid such scenarios from propping up.
In any case, let's not reenable it in this PR pls. Let's reintroduce it separately, ideally on top, and aim to put some numbers in a form of analysis (number of occurences, severity, etc.). I think that would place some proper perspective on the need for it. And add the proper safe guards so it doesn't get lost with non noticing.
Thanks for your following up. I am concerned that this has not been active for an unknown amount of time, no issue reported in the meantime, and today product team quickly jumped the gun to revert work that didn't even cause the breakage, while seemingly magnifying the severity of this issue. This seems rather concerning? Has it ever actually caused problems, as in have we measured this issue or reacted to a regular event happening? Or is this more along the lines of "in case it happens"? In any case, let's not reenable it in this PR pls. Let's reintroduce it separately, ideally on top, and aim to put some numbers in a form of analysis (number of occurences, severity, etc.). I think that would place some proper perspective on the need for it. And add the proper safe guards so it doesn't get lost with non noticing.
Thank you for your feedback.
For Gravatar SDK users, the login flow is a critical part of the user journey. To ensure the SDK functions correctly, we do not allow switching accounts during this process. Preventing users from logging in with a different account is therefore a necessary requirement.
This PR currently omits the previously implemented mechanism that restricts users to the same account (e.g., hiding other login options, disabling email editing, creating an account, etc.). To ensure a smooth migration of the main login page, we will reintroduce that mechanism in a follow-up PR. ( cc @burtrw @jom )
@chriskmnds My commits address the following issues. Please take a look 👀
- Fix styles: Gravatar magic code and WPJ magic link
- Address the button text of the magic login on the main login screen (Related to this PR)
Test Instructions
Preparation
- Check out this PR
- Ensure you are logged out
Test Gravatar Magic Login
- Log in to Gravatar by using this test URL, and you will see the styles have been fixed:
Email form
Secondary email options (login with your Gravatar 2nd email address)
Magic code validation
Test WPJ Magic Login
- Log in to WPJ by using this test URL, and you will see the styles have been fixed:
Email form
Magic link validation
Test The Main Login Screen
- Gravatar: The text of the magic login button should be "Email me a code", and clicking it will bring you to the corresponding screen
- WPJ: The text of the magic login button should be "Email me a link", and clicking it will bring you to the corresponding screen
- WP.com: It should still work the same
@chriskmnds, do you plan to merge and deploy this PR? If not, I’m happy to take care of it. I need your review of my changes first. Thanks!
@chriskmnds, do you plan to merge and deploy this PR? If not, I’m happy to take care of it. I need your review of my changes first. Thanks!
Thanks @wellyshen ! I will review this in a bit and get back with any comments :-)
We really need to get to a place where Gravatar users won't ever see this screen:
- We don't want to support logging in with usernames (email addresses only) and we intentionally minimize passwords as an option (no need to see 'Lost your password'
- There is too much WP.com branding with the logo and the WordPress.com mention in the massive heading - many of our users won't have a clue what WordPress.com is, and this will increase confusion and friction, especially when you consider 3rd parties that integrate with Gravatar that will be asked to connect via oAuth to make updates
- Our users shouldn't be prompted to 'Create an account' - previously, we had it working where there was just one flow - Login/Create was the same. If you enter an email that doesn't have an account, we'd then show you the prompt to agree to Terms and Privacy and then create the account.
We'd love not to need any custom code or flows, but we'd need to be involved and considered in the design phase, not at this late development stage, after it has already been pushed to production. Hopefully, there can be another iteration.
@burtrw Thanks for replying and sharing your thoughts. I can see your point, to have these separate tailored screens perhaps more suited to the intricacies of Gravatar. 🙇♂️
From my perspective, I don't think those intricacies exist in reality (as in, for example, our discussion above), or that WP branding will hurt the Gravatar brand. Ultimately, there is only one brand (WP), and I think no harm in it being transparent that that's the engine behind. I think that understanding alone can make these tailored designs (and logic!) start to feel less and less important/necessary. As with the dozen or so other clients.
That said, I think there are mostly subtle differences design-wise right now that we can align fairly quickly. Would you like to create a few issues in the Linear project for things to tailor beyond design? We can address each one separately . 🙏
Thanks @wellyshen! ❤️ This looks great. Just a couple of things to note:
- The color of "Create an account" CTA in the top-bar should adapt the link color variation for Gravatar. See the images I posted in the description. So this was working at the time of putting together the PR, but something changed since. It's unrelated to this PR as also other OAuth client screens reverted to the dark/default color e.g. for Blaze Pro it's supposed to be orange.
- cc @adamwoodnz – is this related to https://github.com/Automattic/wp-calypso/pull/103616 or any of the other PRs?
- The fonts should also adapt to what Gravatar uses. For example, the header font is still Recoleta, but Gravatar uses
font-family: SF Pro Display,-apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen-Sans, Ubuntu, Cantarell, Helvetica Neue, sans-serif;.- There is a separate Linear issue to address this holistically, as it happens to other OAuth client Logins (issue). But if you can work it out for Gravatar, it would be great (or choose to do it in another PR). I think this would at least bring the two designs a little closer.
So, from me, feel free to decide whether to ship this and work out the above separately, or if you'd rather do it here, or if you'd rather leave it with me. Concerning my thoughts above, on the layout congestion, I will create an issue to decide what to do if we don't take any action here.
Concerning my thoughts above, on the layout congestion, I will create an issue to decide what to do if we don't take any action here.
Sorry - definitely for a separate PR if anything more than general/minor tweaks (like centering the text, removing the background color, etc)
The color of "Create an account" CTA in the top-bar should adapt the link color variation for Gravatar. See the images I posted in the description. So this was working at the time of putting together the PR, but something changed since. It's unrelated to this PR as also other OAuth client screens reverted to the dark/default color e.g. for Blaze Pro it's supposed to be orange.
- cc @adamwoodnz – is this related to Update login form fields to match core components #103616 or any of the other PRs?
Thanks for the ping, it was decided that these navigation link buttons should be dark, unless they are primary buttons.
We really need to get to a place where Gravatar users won't ever see this screen:
From my perspective, I don't think those intricacies exist in reality (as in, for example, our discussion above), or that WP branding will hurt the Gravatar brand.
Let's zoom out a little bit here and take stock of what we're doing. Which is: reducing the number of individual implementations of this login screen from all of them to as few as possible. Branding was always a bit of an open aspect, notably the Recoleta font should only be wp.com specific, and we've talked about how consumers of the componentry can supply little brand pieces like radius, color, etc.
The meta goal here is to lift all boats. If the Gravatar login flow is better, why is it separate and not applied across all? A reasonable argument is: it's a work in progress that's being refined separately, with intent to eventually contribute back to the core flow. That rings true to the ID atelier (puPv3-gMu-p2), which is paused, but nevertheless relevant to the conversation, and I believe kicked off some of the Gravatar login flow changes.
To that end, I'd support Ronnie in suggesting the Gravatar login flow can exist in parallel for a bit. There's a technical question here for Christos—is it possible? I'd hope it is, because Gravatar does seem a reasonable exception as it's already underway. (Some additional feedback on the Gravatar flow here, by the way.)
But let's keep the meta goal in mind: there's no user benefit to multiple different login flows existing, and it comes with code quality and maintenance costs. So if the Gravatar flow once refined is the clearly superior one, why not adopt that across the codebase?
Thanks for looking at this @jasmussen. I totally agree with any argument that this "multiple designs coexisting in the same flow" isn't a great state. My hope was that we'd more actively (with a higher sense of priority) adapt things when the differences are more pronounced (as is the case of Gravatar). For everything else, we'd gradually adapt (over the next couple weeks, it won't take longer). Now it looks to me that we are also questioning the DS Pass, which is beyond my scope or influence with this work.
I think my goal with this work has been clear: (1) unify the designs, (2) get rid of the bloat for enabling variants to begin with. I think with what you are asking, so to answer:
There's a technical question here for Christos—is it possible?
Everything is possible. It's the current state of affairs. We'd be postponing or cutting short a big part of 2 above I think.
@chriskmnds,
Thank you for reviewing.
- I left the "Create an account" text color as dark, due to this comment
- I have addressed the Gravatar fonts issue (736ce90)
If no other issues related to this PR, I will deploy it :)
This PR modifies the release build for the following Calypso Apps:
For info about this notification, see here: PCYsg-OT6-p2
- help-center
- notifications
- wpcom-block-editor
To test WordPress.com changes, run install-plugin.sh $pluginSlug update/connect-refresh-login-gravatar on your sandbox.
Thanks @wellyshen ! You are a star 🌟
If no other issues related to this PR, I will deploy it :)
Please, let's hold off merging until we have a final go from @jasmussen or @burtrw ( concerning comment above: https://github.com/Automattic/wp-calypso/pull/104046#issuecomment-2975315595 ) :-)
Thanks @wellyshen ! You are a star 🌟
If no other issues related to this PR, I will deploy it :)
Please, let's hold off merging until we have a final go from @jasmussen or @burtrw ( concerning comment above: #104046 (comment) ) :-)
No problems, thank you for all the reviews :)
Thanks all for the effort, thanks for the pings.
As noted in the referenced posts: our goal here is deduplication and code quality. The concerns are about some of the local implementations having reached a level of bespoke quality and tested flows, that would be a pity to waste in the name of unification.
From both the Gravatar side, and the unification side, what would you like to see happen? And what might be good technical solutions that can accommodate both?
E.g. do we let the Gravatar and VIP login flows keep their bespoke implementations until some point of maturity, then roll those out across all in place of the initial design principles outline here? Or is there a world where we have two distinct design templates that a consumer can employ; the cardless centered version in this PR and the boxed/carded flow employed by Gravatar/VIP? And if the latter, what does code quality look like in that context?
Notably the effort here includes accessibility improvements to reduce litigation risk in context of the EU accessibility act, as well as advice from legal on where to put the T&S links in the flow. Wherever we end up with, we want to ideally ensure those parts are as inherited as possible in the all implementations.
if the Gravatar flow once refined is the clearly superior one, why not adopt that across the codebase?
This makes a lot of sense to me. Gravatar wasn’t a focus in the initial design exploration, but certainly has things to contribute to a better overall solution.
I'm okay with letting Gravatar and WPVIP stick with their current flows until we have time to properly iterate the auth designs to incorporate their feedback. We’ll need to scope and schedule a design project for that as I don’t think we have any designers with enough free capacity to take that on immediately (at least, not on Dotcom—cc @crisbusquets ).
Thanks for the input @jasmussen @matt-west
do we let the Gravatar and VIP login flows keep their bespoke implementations until some point of maturity, then roll those out across all in place of https://github.com/Automattic/wp-calypso/pull/104109#issuecomment-2975778642?
Solid question! Before the redesign from a few years back (what became isWhiteLogin), we had a boxed layout. Do we expect to bring that back? 🤔
Or is there a world where we have two distinct design templates that a consumer can employ; the cardless centered version in this PR and the boxed/carded flow employed by Gravatar/VIP? And if the latter, what does code quality look like in that context?
Solid question. My question would be, "Why would a client OAuth Login/Signup flow require a boxed layout"? The code quality looks fairly questionable in its current state.
Just to clearify something - we are explicitly discussing the layout here right? (so boxed vs wide design for desktop - cause it's kinda the same on mobile). As far as whether to show "create your account" or "lost password" (and everything else), the two screens contain the same options right now (nothing's lost or added). Unless I'm missing something:
| Before | After |
|---|---|
My opinion:
Proceed with the unification and find some middle ground. Is there no way that we can make quick updates to these other screens to look a little similar? Center the text, remove the boxed layout and background color? I am referring to just layout concerns - the content and other parameters can continue to live as-is. And if we want to remove "WordPress.com" from the title, we can do that.
No strong opinions. Just that there's probably a decent opportunity for quite a bit of cleanup if we keep going.
No strong opinions. Just that there's probably a decent opportunity for quite a bit of cleanup if we keep going.
Double that. Please don't take my comments as pushback. I also had a different impression going into this project (and certainly didn't know there was no buy-in from across the board).
I am more than happy to assume this holds and close the respective PRs tomorrow:
I'm okay with letting Gravatar and WPVIP stick with their current flows until we have time to properly iterate the auth designs to incorporate their feedback. We’ll need to scope and schedule a design project for that as I don’t think we have any designers with enough free capacity to take that on immediately (at least, not on Dotcom—cc @crisbusquets ).
👍
Solid question! Before the redesign from a few years back (what became isWhiteLogin), we had a boxed layout. Do we expect to bring that back? 🤔
Not uniformly. The design here is informed by testing, so it's not a bad design. I'm mainly noting that there is a concerted effort for the same on the Gravatar side of things. It's possible we can unify, though I can also see there existing those two layouts.
If we were to talk about nicely clean componentry, one could be the compact version.
But notably, we're not talking two entirely different implementations here. An end goal should still be one implementation with smart wiggleroom.
Proceed with the unification and find some middle ground. Is there no way that we can make quick updates to these other screens to look a little similar?
In principle this resonates with me, but I'd be keen to hear from the consumers at this point. I'm sure there's nuance driving the bespoke implementation, notably for Gravatar, which is farther advanced than most of the others that have been mostly light reskins.
Center the text, remove the boxed layout and background color?
Fonts, font size, accent colors are already noted as some of the big visual swings we can take.
If the particular implementation truly works best with a boxed layout then I can see that being—if we can implement it cleanly—an extension of that. Though I will say centered text is designed to work with the unboxed version; if we do box it, the boxing should likely come with left alignment.
I'd echo that the fewer overrides we can do, the better, so anything we can do on unifying the element order, buttons, links, phrasing, titles, etc, the better, as those have all received a copy pass from the source side.