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

Domains: Google Apps: Show a domain warning for accepting Gapps' ToS #5476

Merged
merged 1 commit into from
Jun 17, 2016

Conversation

klimeryk
Copy link
Contributor

@klimeryk klimeryk commented May 19, 2016

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:
screen shot 2016-05-28 at 05 51 24

One domain, multiple accounts (notice emails and their list - much plural, such wow):
screen shot 2016-05-28 at 06 04 06

Multiple domains, multiple accounts need verifying:
screen shot 2016-05-28 at 06 10 01

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:

  • the overview of domains for the given site
  • the selected domain
  • overall Google Apps view
  • Email view of the selected domain

Additionally, the severity of the notice is based on the date the subscription started:

  • younger than 7 days - info
  • between 7 and 21 days - warning
  • after 21 days - error

Note that the highest severity should trump all below, so if you have one domain that is info and one that is warning, the overall notice for these domains should be warning (while on the individual domain's views it should be info and warning, respectively).

Added analytics recording the following info for each click on Log in:

  • domain
  • user - user's email
  • severity - the severity of the notice, useful to see what's the most effective severity
  • isMultipleDomains - was the notice for multiple domains or for one selected domain
  • section - the section where the notice was displayed, either domain-management or google-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 ❤️

@klimeryk klimeryk added [Status] In Progress [Type] Task [Feature Group] Emails & Domains Features related to email integrations and domain management. G Suite labels May 19, 2016
@klimeryk klimeryk self-assigned this May 19, 2016
@klimeryk klimeryk force-pushed the add/gapps-tos-notice branch 3 times, most recently from b52d417 to e11a28d Compare May 20, 2016 01:42
@klimeryk klimeryk added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels May 20, 2016
@BrookeDot
Copy link
Contributor

BrookeDot commented May 20, 2016

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:

Please log in and accept Google's Terms of Service to prevent Google Apps suspension. Log in Now
screenshot_19-05-2016-22 43 45

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:

Log in to your hello@example.com Google Apps account to accept Google's Terms of Service to avoid suspension. Check your WordPress.com email, example@gmail.com for log in details. Learn More

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.

Bonus question/idea: should I add some tracking events to see how successful these notices are?

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)

@Lochlaer
Copy link

Can we change the copy here:

b2d7b878-1e3e-11e6-9803-f753aa59c735

To something like this:

Urgent! Log in and activate your Google Apps subscription for the domain example.com now.

@BandonRandon is correct here:

an account is "suspended" from purchase until they first log in no matter the time that takes.

Re: this:

Fix now should redirect to the domain-specific Google Apps view)

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:

https://accounts.google.com/AccountChooser?Email=**user@companyname.com**&service=CPanel&continue=https%3A%2F%2Fadmin.google.com%2F**companyname.com**%2FAcceptTermsOfService%3Fcontinue%3Dhttps%3A%2F%2Fmail.google.com%2Fmail%2Fu%2F1

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.)

Bonus question/idea: should I add some tracking events to see how successful these notices are?

Yes, please.

(Learn more links to https://support.wordpress.com/add-email/adding-google-apps-to-your-site - any suggestions for better target?)

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!

@ranh
Copy link
Contributor

ranh commented May 24, 2016

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

@klimeryk
Copy link
Contributor Author

What is the expected flow for getting a new GApps account? Where does accepting the ToS normally fit in?

When registering a custom domain (through NUX or Domains Management) after selecting the domain from the domain search results you are shown this nudge:

2016-05-24-171612_1157x562_scrot

Click Add Email to add one or more Google Apps accounts to the domain you are buying (one license = one whatever@example.com account).

Is there anything else we or Google are doing to get users to accept the ToS? Emails? Other notices?

After setting up the account (should not be more than a few minutes), the user gets an email from us titled [WordPress.com] Google Apps is now set up and activated for your domain "example.com".:
2016-05-24-172036_1452x1047_scrot

At around the same time you get an email from Google titled You’ve signed up for Google Apps: What’s next?:
2016-05-24-172236_934x1151_scrot

That is - if everything goes smoothly :)
The common issue is the domain not being verified properly (we automatically add the necessary TXT records and retry the verification a few times, but it still seems to fail from time to time). The user can verify it himself (Google sends an email if you don't verify your domain soon after purchase), but we also have HEs do it.

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

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.

@Lochlaer
Copy link

@ranh

What does "your account will get suspended soon" mean? How soon? What is the implication of having the account suspended?

That's why I want to change the copy to something like this:

Urgent! Log in and activate your Google Apps subscription for the domain example.com now.

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 Suspended - Terms of Service in the reseller dashboard.

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?

That is correct.

If so, the ToS is just a technicality, we should focus on getting the account working and getting the user using it

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!

@umurkontaci
Copy link
Contributor

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.' ) }>
Copy link
Contributor

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?

@Lochlaer
Copy link

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.

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 Important:?

@umurkontaci
Copy link
Contributor

This is a nice to have:
image

Instead of just showing the error with a notice above, we can indicate that something is wrong inside the user row as well (maybe something with a red exclamation mark or similar)

@umurkontaci
Copy link
Contributor

umurkontaci commented May 24, 2016

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.

@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."

@umurkontaci umurkontaci added [Status] Needs Author Reply and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels May 24, 2016
@BrookeDot
Copy link
Contributor

BrookeDot commented May 24, 2016

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)

Almost set! To start using your email admin@example.com please log in and accept Google's ToS. Learn More

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:

Almost set! to start receiving email at admin@example.com please follow the instructions sent to user_email@example.com. Learn More.

@umurkontaci
Copy link
Contributor

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)

Almost set! To start using your email admin@example.com please log in and accept Google's ToS. Learn More

I like this copy better than mine!

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.

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.

@BrookeDot
Copy link
Contributor

make use of that information to progressively increase the "urgency" of the message

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.

– we can make a small onboarding process that guides the user to set up things... we can talk about it somewhere else to keep this PR in orbit.

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.

@Lochlaer
Copy link

I like this copy too:

Almost set! To start using your email admin@example.com please log in and accept Google's ToS. Learn More

Corrected to:

Almost set! To start using your email admin@example.com, please log in and accept Google's Terms of Service. Learn More.

Question for @klimeryk : Can we change the Learn More text to Click Here or Log In Now and then link that button to the pointer URL (with the custom domain included) I mentioned in the thread above?

A couple of other considerations:

  • I like the idea of staggering the alerts. We also need to consider that part of the TOS acceptance campaign includes a series of emails (schedule TBD) to send to users reminding them if they haven't logged in yet, so I think a yellow alert at the outset is appropriate, which can be changed to red after a day or so.
  • We also need to consider that part of the roadmap includes changing the purchase flow so that users will be able to create their own passwords/user accounts post-purchase, so this flow we're discussing may or may not change (depending on if/when we roll out that change.

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!

@BrookeDot
Copy link
Contributor

BrookeDot commented May 25, 2016

@Lochlaer, are you suggesting that in the alert we nix the "Learn More" link and change it to Click Here" or is this just for the "Log in" text to redirect the pointer URL above.

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 Learn More link somewhere else so that it doesn't compete with the real CTA we're trying to convey. At this point, the copy should be pretty clear as to why they're logging in -- they need to activate their new email address on Google Apps.

@klimeryk
Copy link
Contributor Author

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).

@ranh
Copy link
Contributor

ranh commented May 26, 2016

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?

You're almost there! To activate your email admin@example.com, please log in to Google Apps and finish setting it up. Learn More.

@klimeryk
Copy link
Contributor Author

@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 lib/analytics/ has to be mocked, but as I use only the mixin directly lib/mixins/analytics/, I'm not sure how to proceed (and all of my sane and insane attempts at fixing this have failed).

@umurkontaci
Copy link
Contributor

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

import mockery from 'mockery'
describe('test', () => {
  let Component;
  before( () => {
    mockery.registerMock('lib/analytics', {})
    Component = require('../component');
  } );
  after(() => {
    mockery.deregisterMock('lib/analytics');
  } );

@klimeryk
Copy link
Contributor Author

klimeryk commented May 31, 2016

Thanks a lot, @umurkontaci! 🙇 All green, ready for another review!
I've updated the original post, please re-read it and make sure I've included all the suggested edits and improvements.

@klimeryk klimeryk added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels May 31, 2016
@BrookeDot
Copy link
Contributor

Worked in testing:
screenshot_31-05-2016-21 56 43

isMultipleDomains,
section
}
);
Copy link
Contributor

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

@umurkontaci
Copy link
Contributor

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.

@klimeryk
Copy link
Contributor Author

klimeryk commented Jun 3, 2016

@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, info => You're almost done!, warning => Attention!, error => Urgent!.

@@ -28,14 +28,14 @@ const GoogleAppsUsers = React.createClass( {
user: React.PropTypes.object.isRequired
},

getDomains() {
getDomainsAsList() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@umurkontaci
Copy link
Contributor

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 :)

@klimeryk
Copy link
Contributor Author

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" />;
Copy link
Contributor

@umurkontaci umurkontaci Jun 16, 2016

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

Copy link
Contributor Author

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!

@umurkontaci
Copy link
Contributor

Changes look good, did a partial test.

I have one comment on existence of selectedSite, add that, do a rebase with master and it's good to go. No need for another review
👍

@umurkontaci umurkontaci added [Status] Needs Author Reply and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Jun 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature Group] Emails & Domains Features related to email integrations and domain management. G Suite [Type] Task
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants