Alternative login with site URL

[bummytime]

Steps to implement:

• [x] Find where the Site URL button is turned off. Turn it back on again.
• [x] Find where in the code to check if the login supports Jetpack
• [x] Figure out how to check if the site supports Jetpack
• [x] Build in a split path, so that Woo can configure and block users without Jetpack, but also allow WordPress users to continue.
• [x] The split path will need to throw an error of some kind for the Woo side.
• [x] Update the host app WPiOS and check that the new defaults work smoothly. (Defaults should all be set for WP).
• [x] Update the host app WCiOS and check that the new configurations work smoothly.

[jleandroperez]

(For reference!) Related android PR Here

[bummytime]

I wanted to add some notes to this issue while I was researching it.

1. If we turn this feature on, I think there's going to be a confusing UX emerging here → we are bypassing the .com username/password screens to enter a site address and then enter...a username and password. I guess am not sure what the goal of this flow is then. :-)

2. In WPiOS, we don't allow the user to select the .org login, enter a .com/JP site, and then input their .com creds (an error will appear). So we will need a new mode that forces the .org login flow to only do a .com login (Android did this already). Again, I can't help but wonder if this makes sense? (see my point 1 ☝️ )

3. I am assuming we would want to bypass the site picker screen since we already provided a specific site. If we would do this, we would need to refactor a lot of logic that is currently on the Site Picker screen: WC requirements check, setting the default site, etc. Also, I should note that, WCAndroid currently navigates the user to the site picker screen after going through this login flow:

@astralbodies @jleandroperez @mindgraffiti let me know your thoughts here! Thanks!!

[bummytime]

Oh, and ping @kyleaparker as well :-)

[jleandroperez]

I think this feature is off:

0. We support Dotcom + Self Hosted Stores ONLY
1. A URL doesn't necessarily maps to a single WordPress.com user. One URL may have multiple users
2. Because of the above, displaying the URL doesn't necessarily save you from typing your username

The URL Login flow is more appropriate for Self Hosted scenarios IMO. I'm not sure if i'm missing something, but i'd vote we close this one, since it's not really applicable.

[mindgraffiti]

Thanks for checking into this @bummytime.

Agreed, that flow is incredibly confusing. It didn't even occur to me that we've been solving this problem all along in our main login flow. A user can already access their self-hosted site in the main flow, so this task is not needed.

[aforcier]

I think the main problem solved by a URL login option is that not everyone is aware of their WP.com e-mail address, and we don't allow you to use your username on the default screen.

Also, allowing a user to enter a site URL gives us a chance to validate and confirm to them if they even have Jetpack set up for that site, which is potentially more definitive/less frustrating than trying to guess e-mail addresses. I think we might be making some assumptions about how users think about their site vs their WordPress.com account that the original research that prompted this design for the login flow covered (though of course it's made murkier by the fact that we don't support non-Jetpack self-hosted sites).

I agree though the flow with the site picker isn't too ideal - we have a ticket open in WooAndroid still to update that flow, but it just hasn't happened yet (https://github.com/woocommerce/woocommerce-android/issues/79).

[jleandroperez]

The huge detail is that... 1 Site URL maps to N usernames, so there isn't a real gain from typing the Site URL (afaik!)

[aforcier]

The huge detail is that... 1 Site URL maps to N usernames, so there isn't a real gain from typing the Site URL (afaik!)

It's not so much about saving typing, but about providing alternate paths to users who get lost. The login by URL might help you if:

1. You know your username, but not your e-mail address (granted it's not clear that this path will let you use a username, but if all you have is a URL and a username, maybe you go that route)
2. You're trying to login by e-mail and it's failing, and the issue is that your site isn't Jetpack connected (we can't tell you that based on your incorrect username/password - but we can tell you that if you tell us the site you're trying to access)

[jleandroperez]

IMHO the proper way to approach (1) (you know your username, but not the email) is to simply add support for Username + Password authentication.

As per (2), perhaps the Site Picker should have a legend / help section Cant find your site here?.

[aforcier]

IMHO the proper way to approach (1) (you know your username, but not the email) is to simply add support for Username + Password authentication.

I tend to agree from a personal standpoint, but the user research that informed the login flow designs demonstrated otherwise. It's been made clear before that our individual intuitions around login often don't match users' expectations.

As per (2), perhaps the Site Picker should have a legend / help section Cant find your site here?.

That wouldn't help you if you can't login in the first place 🙃

[jleandroperez]

So you suggest we...

1. Have a site URL field. This would let us check if the Site is Jetpack enabled
2. Have Username / Password fields

Would that be accurate?.

Point (1) makes sense, would let us catch a specific corner case. But then we should probably support both Username + Email (which means: we go back to the first UI, but with Username support).

[bummytime]

Excellent debate @aforcier and @jleandroperez! @aforcier do we have any data on the usage of site login from our beta testers?

[aforcier]

@aforcier do we have any data on the usage of site login from our beta testers?

We have a decent set of data - I'll follow up with you.

[AmandaRiu]

Lots of good stuff here. I just thought I'd add my two cents as well. This is all based off my current assumptions and understandings so feel free to correct anything I fumble here 😺

I think we might be making some assumptions about how users think about their site vs their WordPress.com account that the original research that prompted this design for the login flow covered (though of course it's made murkier by the fact that we don't support non-Jetpack self-hosted sites).

This is the part that's really sticky though. I believe the part about the research, but it seems like the true purpose of this option is to give a self-hosted user an option to login to their site using their credentials from their self hosted installation right? In that case, this option makes perfect sense, but when I get to this page and enter my site, my intuition tells me that the username and password fields are for the site, not WPcom. I can see where this will be very confusing for the user.

Also, allowing a user to enter a site URL gives us a chance to validate and confirm to them if they even have Jetpack set up for that site, which is potentially more definitive/less frustrating than trying to guess e-mail addresses.

This may be true, but since we only use WPcom creds for both the email and site login pages, having just a simple Login w/ Username page would make much more sense. We know they need that first and foremost. If they get to the Store Selector and no stores are found, that would probably be a great time to ask them to type in the url to their self-hosted site so we can validate it's Jetpack installation.