Plans: update grid for introductory offers

[michaeldcain]

This updates the plans grid to properly account for different introductory offers for WPcom plans. It updates the Introductory Offer plan descriptions and consolidates some of the display logic between discounts and introductory offers.

Requires: D134559-code See: pbOQVh-4sd-p2

Before	After

To test:

• enable Store Sandbox and sandbox public-api.wordpress.com
• create a new user, or use a user that has not previously subscribed to one of these plans
• change your user currency to MXN, PHP, or INR
• create a new site and verify that the different plans grids correctly reflect the introductory offer pricing (reduced monthly breakdown, intro offer full price in the description, and correct billing term in the description)

[github-actions[bot]]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-121319

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-121319&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-121319&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~37 bytes added 📈 [gzipped])

name                  parsed_size           gzip_size
hosting                    +436 B  (+0.0%)      +36 B  (+0.0%)
update-design-flow         +245 B  (+0.0%)       +1 B  (+0.0%)
plugins                    +245 B  (+0.0%)       +1 B  (+0.0%)
plans                      +245 B  (+0.0%)       +1 B  (+0.0%)
link-in-bio-tld-flow       +245 B  (+0.0%)       +1 B  (+0.0%)
jetpack-app                +245 B  (+0.1%)       +1 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 (~1 bytes added 📈 [gzipped])

name                                             parsed_size           gzip_size
async-load-signup-steps-plans-theme-preselected       +245 B  (+0.1%)       +1 B  (+0.0%)
async-load-signup-steps-plans                         +245 B  (+0.1%)       +1 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.

[michaeldcain]

@chriskmnds thanks for the review! I tried to justify my changes in some comment, but I'd be happy to revert them if you'd like me to.

[chriskmnds]

@michaeldcain Sorry for delay in reply. If you can wait another day i can take a closer look and share the original reasoning/posts behind the existing styling. My impression is we at least need to notify WooExpress designers about changing that badge styling. We could also create a separate one if we need to diverge from the all-caps blue-letters badge.

[michaeldcain]

@chriskmnds thanks for all of the additional context. I'll make some additional changes this week and won't merge this without an approval from you.

[michaeldcain]

@chriskmnds after seeing a number of new WPcom introductory offers being discussed (e.g. the new Migration Creator trial), I dusted this off and went ahead and rebased it and the backend diff.

Given that Woo Express plans have been replaced with WPcom e-commerce trials/introductory offers, and there wasn't any pushback to the design changes above, I think it might make sense to proceed with the changes here. Do you mind giving it a review?

[chriskmnds]

@chriskmnds after seeing a number of new WPcom introductory offers being discussed (e.g. the new Migration Creator trial), I dusted this off and went ahead and rebased it and the backend diff.

Given that Woo Express plans have been replaced with WPcom e-commerce trials/introductory offers, and there wasn't any pushback to the design changes above, I think it might make sense to proceed with the changes here. Do you mind giving it a review?

Nice. Yes, having a single base style/design for these makes sense. There was a part where I noticed the cross-out pricing only showed for large-currency, so I'm looking into verifying that. I'll post an update in a bit.

[michaeldcain]

@chriskmnds Thanks for the review! Sorry I missed something from your initial feedback. I'll take a look shortly.

I also can't get the intro offers to show

Is this for a new or existing user? Can you share the username? One of the biggest differences between using the hardcoded cost override and introductory offers is that introductory offers guard against a user cancelling a plan and then resubscribing with the same offer (something the hardcoded override doesn't account for). If your user has ever had a subscription for one of these plans in the past, the introductory offer won't be available.

[chriskmnds]

Is this for a new or existing user? Can you share the username?

Existing user - chriskmnds

One of the biggest differences between using the hardcoded cost override and introductory offers is that introductory offers guard against a user cancelling a plan and then resubscribing with the same offer (something the hardcoded override doesn't account for). If your user has ever had a subscription for one of these plans in the past, the introductory offer won't be available.

This sounds like the reason for not seeing them. These additional restrictions that you mention, do they carry over to the fist-year currency discounts? We haven't had these same restrictions so far right?

p.s. something's not quite right on my end now - in production, I see the first-year currency discounts rendering like intro offers, like this (not through this PR):

Not sure if we shipped something in the tables that produce these intro offers, or if something's off with my account. Can you confirm if production (/start/plans) renders the currency discounts as previously?

---

Curious if we should also remove the isGridPlanOneTimeDiscounted blocks/logic as we don't render any other form of "on-time discount" in the grid right now (this was the only case). I can create a follow-up issue to investigate once this is deployed. Let me know pls.

Never mind this comment. We render the "one time discount" label for coupon discounts, so there's still use for them.

[michaeldcain]

These additional restrictions that you mention, do they carry over to the fist-year currency discounts? We haven't had these same restrictions so far right?

The introductory offer eligibility restrictions close a loophole in the logic that the previous first-year currency discounts had. The Woo Express discounts were always introductory offers, so behaved in the same way as the new currency-based introductory offers.

The reasons for migrating the first-year currency discounts to introductory offers can be seen in many of the issues from this post: p58i-fkS-p2

p.s. something's not quite right on my end now - in production, I see the first-year currency discounts rendering like intro offers, like this (not through this PR):

I think that you're seeing a mix of the currency-based introductory offers (by having Store Sandbox enabled) and the first-year cost overrides, but in production they render with the same logic that was used to show the Woo Express introductory offers. This kind of confusion is why I want to get this PR wrapped up.

Here are the two variations based on Store sandbox vs production tables (there's an indicator in the environment badge):

Production Tables	Store Sandbox Tables

[jeyip]

Hi @michaeldcain!

I'm being asked to shape a second attempt at intro offers for annual plans ( p5uIfZ-fwN-p2#comment-23600 ). You can see the shaping doc here 1gTMlUooqddT2PJ5UNvcMdMlVfCaeRUqSrAA4Tpbx7vI-gdoc. We'll probably run the intro offers as an experiment, and the results will be used to help inform how we'd like to handle pricing in the larger Dotcom Packaging 2024 project.

If I understand this PR and this diff D134559-code correctly, we want to consolidate intro offer logic and one-time currency discount logic ( which are currently treated differently ). If this is the case do you happen to have a sense of how much more effort it would take to get these changes over the finish line?

[michaeldcain]

If I understand this PR and this diff D134559-code correctly, we want to consolidate intro offer logic and one-time currency discount logic ( which are currently treated differently ). If this is the case do you happen to have a sense of how much more effort it would take to get these changes over the finish line?

@jeyip the backend diff is ready to go. I think this needs a rebase and then to address the feedback in this comment. I'd guess it could be ready in less than 2 days.

[jeyip]

Thanks for the update @michaeldcain!

[sirbrillig]

I'm not certain what happened to this PR (I was on sabbatical at the time) but clearly the "2 days" it was going to take have expired 😅 . It's currently needed for a new project (offering discounted pricing for IDR and THB) so I thought I'd resurrect it and complete the work. I've rebased the changes and fixed merge conflicts on both this PR and D134559-code.

I also updated the screenshots in the description to compare the current look.

[sirbrillig]

So all good code-wise. The only thing I notice is a slight design detail in the billing description. It looks a bit weird with the line wrap

That's a good point! The issue is that all the strings in usePlanBillingDescription() have a br tag hard-coded inside them. IMO this is a poor idea since it puts a style issue in the hands of a (localized) string instead of at the level of CSS. I'd be inclined to remove all those br tags, but for two things:

1. The br tags exist before this PR as well and cover a bunch of strings this PR does not modify.
2. It still doesn't look ideal to me with the br tags removed and probably could use some additional styling changes to compensate.

So I'm not sure this is the PR to fix that. Maybe a follow-up? What do you think @chriskmnds?

For reference, here's how it would look with the br tags removed:

[sirbrillig]

Yep. I think adding the price after per month in this PR exacerbates the issue more. Do we need that btw? Can't we keep the first line as per month, for your first year, like it was before?

Yeah, I think that's a good idea. I assume it's like that because all the other strings in this function do the same thing. However, I can try to make it the same as the old text and we can always update strings later. I'll make that change before going forward.

[sirbrillig]

I updated the screenshots in the description to show how it looks now with the price after the intro offer removed (the text now looks the same). I'm not sure it's the best idea but it keeps things looking the same. We can adjust it later.

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• blaze-dashboard
• command-palette-wp-admin
• notifications
• odyssey-stats
• whats-new

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/plans-intro-offer-support on your sandbox.

[chriskmnds]

Hey @sirbrillig

I updated the screenshots in the description to show how it looks now with the price after the intro offer removed. I'm not sure it's the best idea but it keeps things looking the same. We can adjust it later.

Seen it. FWIW - without looking closer - I was referring to just the price part next to the "per month", not the whole last line.

So instead of:

per month, MX$432 for your first year,
then MX$540 billed annually, excl. taxes

to have:

per month, for your first year,
then MX$540 billed annually, excl. taxes

I think that's how it was before? 🤔

[sirbrillig]

I think that's how it was before?

I can do that if you want, but that's not how it is in production now. See the "Before" screenshot.

[sirbrillig]

Oh, you might see what you are describing if you don't have the backend patch applied when testing or if it's applied when you are testing production. I'll update the testing instructions to include mentioning that.

And, if you're testing what it looks like currently make sure that the backend patch is not applied and then you don't have the API sandboxed.

This change and the backend change have to go together.

[chriskmnds]

@sirbrillig

Oh, you might see what you are describing if you don't have the backend patch applied when testing or if it's applied when you are testing production. I'll update the testing instructions to include mentioning that.

And, if you're testing what it looks like currently make sure that the backend patch is not applied and then you don't have the API sandboxed.

This change and the backend change have to go together.

Yes, I am aware. That's how I tested it (with the backend diff). I was only referring to the examples we both shared above and the updated screenshots in the description, which were showing the shorter string. They are probably on some different term variation, so my bad?

I left a couple of comments here and here though if you can take a look? I don't understand the motivation for changing these descriptions, especially with a "we should bring them back" note. 🤔

[sirbrillig]

@chriskmnds Thank you for the comments! I'm sorry. I may have misunderstood what you were looking for.

Basically, my motivation for this PR is to remove the current discount hack that is in place for these currencies and convert them to introductory offers; however, without this PR, introductory offers are not displayed correctly on the plans page. I'm not worried about the specifics of the text at the moment as long as it's accurate. The text can always be updated.

The reason I had changed the text in 2d2040d to remove the last line was so that the text for the new introductory offers would remain unchanged from how it looks currently. However, all the other strings returned by usePlanBillingDescription() for introductory offers display the regular recurring price, and by removing the regular price just for yearly plans, I figured someone would wonder why it was different from the others, which is why I had left the note comment to direct them to this discussion.

I've reverted 2d2040d so that all the strings returned by usePlanBillingDescription() are once again the same format. I'm happy to change the strings to whatever you'd like, though. Just let me know how you want it to read.

[chriskmnds]

@sirbrillig

The reason I had changed the text in 2d2040d to remove the last line was so that the text for the new introductory offers would remain unchanged from how it looks currently. However, all the other strings returned by usePlanBillingDescription() for introductory offers display the regular recurring price, and by removing the regular price just for yearly plans, I figured someone would wonder why it was different from the others, which is why I had left the note comment to direct them to this discussion.

I've reverted 2d2040d so that all the strings returned by usePlanBillingDescription() are once again the same format. I'm happy to change the strings to whatever you'd like, though. Just let me know how you want it to read.

Gotcha. Thanks for explaining. I'm sorry if I came across as a little confused all around. I haven't been looking into pricing UI for more than a month now. Please go by your best judgment. My suggestion would be to keep things as they are in production now, so if that's what the changes were doing, then no need to revert. When we start serving intro offers outside of the (current) first-year currency discounts, we'll obviously revisit the strings.

Thanks for the great work and follow-ups! 💪

[sirbrillig]

After discussing with the team, we've opted to merge this as-is and address any additional wording changes in follow-up PRs. There's a lot that could be done to improve the wording but this PR mainly just fills in missing behavior and isn't intended to be a design change. I've updated the description of the PR to clarify that point with a big NOTE to any future readers. I've also verified that the logged-out view supports the new plans and added screenshots for that.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/16898984

Some locales (Hebrew, Japanese) have been temporarily machine-translated due to translator availability. All other translations are usually ready within a few days. Untranslated and machine-translated strings will be sent for translation next Monday and are expected to be completed by the following Friday.

Thank you @michaeldcain for including a screenshot in the description! This is really helpful for our translators.

[niranjan-uma-shankar]

FYI that the strings visible in production are not translated.

The i18n bot says that ja is machine-translated but I don't see it. cc @Automattic/i18n

[a8ci18n]

Translation for this Pull Request has now been finished.

[dlind1]

FYI that the strings visible in production are not translated.

The i18n bot says that ja is machine-translated but I don't see it. cc @Automattic/i18n

Looks good to me now. We've had an issue with importing new originals into GlotPress and also weren't deploying the translations most of the last week. The Japanese translations were successfully deployed about 14 hours ago.