-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Domains: Google Apps: Show a domain warning for accepting Gapps' ToS #5476
Conversation
b52d417
to
e11a28d
Compare
To be honest, I'm not sure how the suspension process works. It's my understanding that an account is "suspended" from purchase until they first log in no matter the time that takes. Hopefully @Lochlaer can clarify things a bit for everyone. I have gone ahead and tested the patch with a new Google Apps purchase. It works as described above. Here's some additional feedback. @Rahn may also have some comments about the copy. I just wanted to mention I don't love "fix now." makes it sound like something's broken what about:
I'm also wondering if there is a technical reason why we are not just sending the user to Google's log in screen from the first two alert locations (Domain Management - All and Domain Management - Single) Seems like this could save a click. The advantage of having both alerts is that hopefully the user will read them both but one longer alert may be better here. I also think it's a good idea to let the user know where to find the log in information. I do know this is included in the "Learn More" link but wonder if we should also add it to the message:
Speaking of the Learn More link in the alert, can we update the location to: https://en.support.wordpress.com/adding-google-apps-to-your-site/#completing-sign-up This goes over the completing sign up steps we're trying to get the user to complete with these steps.
I think adding a track to see how many people click at each step could be helpful and potentially help us remove/streamline this flow in the future. (For example, do people log in more from the domains manager or email manager, which A/B test of text works better etc) |
Can we change the copy here: To something like this:
@BandonRandon is correct here:
Re: this:
Yes. More specifically, if possible it should redirect to the target URL so that there's no confusion if the user has multiple Google Apps/Gmail accounts. For example: This is the pointer URL that Dennis at Google recommends to avoid the conflicting login pages altogether. ( /cc @matthusby because we talked about this before as a possibility.)
Yes, please.
Yes - a new page that's more targeted at users who've already purchased Google Apps. :-) For now, can you please just use the one that @BandonRandon recommends above and then I'll work on a new doc that will be more appropriate? Thanks! |
I was not able to get these notices to show up. I could use some more information about this whole process. What is the expected flow for getting a new GApps account? Where does accepting the ToS normally fit in? Is there anything else we or Google are doing to get users to accept the ToS? Emails? Other notices? What does "your account will get suspended soon" mean? How soon? What is the implication of having the account suspended? From what I understand, accepting the ToS is the first thing one does with GApps, so if a user hasn't accepted the ToS, it means they haven't used their GApps account at all. Is that correct? If so, the ToS is just a technicality, we should focus on getting the account working and getting the user using it |
When registering a custom domain (through NUX or Domains Management) after selecting the domain from the domain search results you are shown this nudge: Click
After setting up the account (should not be more than a few minutes), the user gets an email from us titled At around the same time you get an email from Google titled That is - if everything goes smoothly :)
I'll let @Lochlaer answer these ones, as she is more familiar with the process, the numbers behind it and how it looks compared to other resellers. |
That's why I want to change the copy to something like this:
It's already suspended, so "your account will be suspended soon" doesn't really make sense. The account is automatically in a suspended state upon creation/provisioning until the user logs in for the first time and accepts Google's TOS and reseller agreement. Until the user does that, they're unable to use the account and it continues to show as
That is correct.
Totally a technicality and probably one of the biggest blockers to product adoption (which Google defines as when the user logs in at least once every 30 days). The idea is to reduce/eliminate the friction from purchase to initial sign-in. Hope that clarifies things! |
Can we remove "Urgent !" from the beginning of the message? Just because they didn't accept Google Apps ToS doesn't mean we should scare the hell out of them and make them uncomfortable and indicate something is terribly wrong. I think a positive reinforcement in this case will go a long way. |
status="is-error" | ||
showDismiss={ false } | ||
key="pending-gapps-tos-acceptance-domains" | ||
text={ this.translate( 'Urgent! You need to accept Google\'s Terms of Service or else your Google Apps accounts will get suspended soon.' ) }> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We know the domains, why not show them in the message?
I'd really like to have something that conveys the, well, urgency of logging in and thus activating their account. The user has paid a lot of money for this particular product, so we want to make sure that this last step is top-of-mind when they log into their dashboard so that they can start using it right away. Alternative suggestions welcome! Maybe |
@Lochlaer Just because you paid good money doesn't mean you should urgently set it up though :) I definitely agree we need to max ToS acceptance, but I don't think it's a good idea to overwhelm the user. They buy a domain and Google Apps from us, and they receive 2 urgent warnings (ICANN confirmation and Google Apps Tos) and one yellow warning (new domain setting up) as if all hell broke loose and it's their fault. I think this is too much. I think we can do much better by holding the their hands and show them the right path. Couple of things to consider in here; it's still early to assume the user knows what Google Apps is. I thought Google Apps was Google Maps, Google+ and such before. Almost everyone buys it for email and we can use that. How about something along the lines of "Finish setting up your email admin@example.com, you will not receive or send messages until then." |
I like where @umurkontaci is going with this positive reinforcement thing. What about something like we do for domain mappings/registrations (showing the yellow warning instead of the red error)
You also make a good point about all the warnings and emails we send. I wonder if we can do something like delay this message for 24 hours after signup (or until the yellow domain alert goes away). If the user still hasn't logged in then show the error. I'm also making the assumption the user will be setting their own password via the flow. If this is not the case we should let them know where to find the log in information. I would expect this may be where some of the confusion is coming from. Users who want to log in but don't know how. If we are still setting a temporary password I would change the message to something more along the lines of:
|
I like this copy better than mine!
Not sure if the signup timestamp information for Google Apps accounts is readily available, but for domains it is. We can make use of that information to progressively increase the "urgency" of the message as well. Also, instead of showing these as notices – which was done because it was easy – we can make a small onboarding process that guides the user to set up things; similar to some companies do on post-signup with progress bars and steps. It's an idea for the future though, we can talk about it somewhere else to keep this PR in orbit. |
I love this idea! No need to sound all alarms from the start, but multiple alerts may allows the user to know that this needs to be done.
I agree that this is best for a conversation elsewhere. I just wanted to say ideally we'd have both. Combining both the drip/welcome stuff that other teams are doing with the alerts here. Ultimately our goal is to to make it as simple for users to be aware how WordPress.com works and the steps they need to take. Just like different people have different communication styles, they may respond to various alerts differently. |
I like this copy too:
Corrected to:
Question for @klimeryk : Can we change the A couple of other considerations:
I had other comments about the TOS acceptance campaign in Slack, but I don't want to delay deployment of this. Let's Track it and see how things go! @ranh Comments/feedback welcome on the copy! |
I don't think we should get rid of the link to the support document found under "Learn More" as this could help some users if they have trouble with the log in link. Yeah, or at least move the |
So much great ideas - thanks guys and gals! I especially like the positive wording of @umurkontaci's suggestion and the progressive increase in urgency of the notice. I'll start working on implementing those changes ASAP (the copy can be tweaked easily if needed). |
I like this direction. I think we can still lose the reference to suspension and the ToS, we're the only ones who care about that. The focus should be on using the product. How about this?
|
@umurkontaci: as we discussed on Slack yesterday, I'd really appreciate at least some kind of pointer/example on how to fix the issue that is preventing the tests from succeeding. I understand that |
This has a good example on what to do: https://github.com/Automattic/wp-calypso/blob/master/client/components/search/test/index.jsx#L20 The core ideas is you want to register a mock before importing the component you are about to the test. The example I gave you is more or less the convention we follow along with some helper functions. At a bare minimum you need
|
24d5352
to
f4c2cfd
Compare
Thanks a lot, @umurkontaci! 🙇 All green, ready for another review! |
isMultipleDomains, | ||
section | ||
} | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be nice to record impressions as well so we have a proper conversion measure
I've tested in on Domains list and edit pages and they are working as they should. Left a couple of comments on code, I think tracking impressions is the most important thing there. I'm OK if you want to follow up with the other ones another day. |
@umurkontaci - thanks for the review, very good points - hopefully I've addressed them all :) I even caught one old bug related to tracking in Google Apps view (see 9099171) 😁 As for the different copy for different severities - I've changed the exclamation that the notice starts based on the severity, I hope that's enough. So, |
@@ -28,14 +28,14 @@ const GoogleAppsUsers = React.createClass( { | |||
user: React.PropTypes.object.isRequired | |||
}, | |||
|
|||
getDomains() { | |||
getDomainsAsList() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
General testing shows it looks like it's working, but I wasn't able to test anything under Google Apps tab as it is broken for me. I think that piece was tested before so that part should be working :) |
Thanks for the feedback - I've addressed the issues you've pointed out and it's ready for another review 🙇 |
@@ -221,7 +221,7 @@ export default React.createClass( { | |||
domain.googleAppsSubscription && | |||
domain.googleAppsSubscription.pendingUsers && | |||
domain.googleAppsSubscription.pendingUsers.length !== 0 ); | |||
return pendingDomains.length !== 0 && <PendingGappsTosNotice key="pending-gapps-tos-notice" site={ this.props.selectedSite } domains={ pendingDomains } section="domain-management" />; | |||
return pendingDomains.length !== 0 && <PendingGappsTosNotice key="pending-gapps-tos-notice" siteSlug={ this.props.selectedSite.slug } domains={ pendingDomains } section="domain-management" />; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can selectedSite
be false
here? Seems like we defined selectedSite
propType to be a bool or an object, this may need a this.props.selectedSite && this.props.selectedSite.slug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and no - it can be passed false
from CurrentSite
(which, despite its name, is also shown when browsing all your sites), but the rule for showing this notice is not whitelisted in that context. Nevertheless, to be on the safe side, I've added the check - good catch!
Changes look good, did a partial test. I have one comment on existence of |
436b13e
to
5c3c038
Compare
The purpose of this PR is to add a notice in Domain Management notifying the user that has purchased Google Apps account(s) that he/she has to log in to them in order to "activate" them (bascially, accept Google's Terms of Service).
One domain, one account needs verifying:
One domain, multiple accounts (notice
emails
and their list - much plural, such wow):Multiple domains, multiple accounts need verifying:
The
Learn more
link leads to https://en.support.wordpress.com/adding-google-apps-to-your-site/#completing-sign-up.The
Log in
links should lead to a prefilled Google's login form - the form is prefilled with the first unverified email from the domain. Why? Because logging in into one of the unverified accounts, verifies the rest of them for the given domain.These notices should show up in Domain Management:
Email
view of the selected domainAdditionally, the severity of the notice is based on the date the subscription started:
info
warning
error
Note that the highest severity should trump all below, so if you have one domain that is
info
and one that iswarning
, the overall notice for these domains should bewarning
(while on the individual domain's views it should beinfo
andwarning
, respectively).Added analytics recording the following info for each click on
Log in
:domain
user
- user's emailseverity
- the severity of the notice, useful to see what's the most effective severityisMultipleDomains
- was the notice for multiple domains or for one selected domainsection
- the section where the notice was displayed, eitherdomain-management
orgoogle-apps
Let me know if that's enough info, if I've missed something and if I've done this analytics thing correctly at all 😁
Of course, if you don't have Gapps, or all your accounts have accepted the ToS, none of these notices should be shown.
Backend changes are backwards compatible and have been merged already, so this can be tested without a sandbox 👍
/cc @aidvu @umurkontaci @matthusby @rads for code review
/cc @ranh for converting my derp-speak to something understandable by users and concise 😉
/cc @Lochlaer @BandonRandon because you're awesome like that ❤️