Let's keep them as a single page. On the email preferences pages we accept a 'variant' parameter which can load a different template. We could do something similar here.

We can definitely add an 'other' amount field - that should have its own phab ticket, with text specified for validation error messages (too big, zero, negative)

We can also show the total amount, and that could also merit its own phab task. I'm guessing it should dynamically update based on the donor's selection, and update on each key press when the donor is typing an 'other' amount?

@ehughes The mustache templates are found here: https://phabricator.wikimedia.org/diffusion/EDOI/browse/master/email_forms/templates/ (the files starting with recurUpgrade).
The CSS is here (shared with the email prefs form) https://phabricator.wikimedia.org/diffusion/EDOI/browse/master/modules/css/emailPreferences.css
And the (minimal) JS is here: https://phabricator.wikimedia.org/diffusion/EDOI/browse/master/modules/js/ext.donationInterface.recurUpgrade.js
Here's a zipped version of the rendered page with all resources: https://phabricator.wikimedia.org/F41746657

Thanks Elliott, the variant parameter sounds smart.

Here's the request for the 'Other amount' https://phabricator.wikimedia.org/T356478

Here's the reques to show total amount https://phabricator.wikimedia.org/T356479

@ehughes The fr-tech team is trying to estimate how much work we will need to implement this, and that would depend on what we get from you. Were you planning to deliver HTML and CSS, or just a visual design?

Hi @Ejegg ! I was planning to deliver HTML and CSS to you if thats OK at your end. :)

Awesome @ehughes, that's what we were hoping to hear!

Hi @Ejegg,

I've attached a ZIP file of the HTML/CSS for the landing page. I had to add in the html structure to get it to show properly on a browser for me but hopefully it's easy enough for you to work around. Let me know if you'd need me to take those out again!

I've also just commented out your replacements to put in the copy to demonstrate what needs to be where and in what format (for dates etc).

There is one new bit of JS which swaps out the final sentence before the buttons once someone makes a selection. The new updated amount is included in here but I haven't done any calculation as I wasn't sure if that would be better done at your end! Please let me know if there's anything else you need me to do or if you have any questions :)

Cheers!
Emma

Tagging @MSuijkerbuijk_WMF and @spatton for visibility!

@Ejegg We are working with email team on the email push. The delivery date is March 20th, and I'm adding @PPenloglou-WMF here so he can tell us the latest date to receive this URL. Note: Sam and I will need to QA.
@PPenloglou-WMF I suggested to the team that URL will be ready for the Tech QA dates (~March 15), I hope that's possible. Please let Elliott and me know.

Change 1008974 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] WIP new variant for recurring upgrade landing pages

https://gerrit.wikimedia.org/r/1008974

Thanks @ehughes, those files are perfect. I've started to adapt them for use with the dynamic content.

Change 1008980 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Alphabetize some email form things

https://gerrit.wikimedia.org/r/1008980

Change 1008982 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Move $recurringOptions calculation out of EmailForm

https://gerrit.wikimedia.org/r/1008982

@ehughes, one question on how the form is supposed to work. There is a bit of text that is initially hidden with the NEW amount and charge date. This seems like it's supposed to appear as soon as the donor selects an amount (before they have actually submitted the form).

However, the text makes it seem like they're all done, and I'm afraid some donors won't go on to click the submit button:

Your new monthly donation amount of $2.75 will apply on your next donation date of Mar 12, 2024.

How about we change that to

You are increasing your monthly donation amount to $2.75.

and then show the supplied text on the success page?

@ehughes I'm also going to tweak the supplied CSS a bit to make the submit button greyed out until the donor selects a valid amount

@Ejegg Thanks for this, I would defer to @MSuijkerbuijk_WMF and/or @spatton for final decision regarding the text change! But it makes sense to me to do that, for what its worth :)

Change 1008980 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Alphabetize some email form things

https://gerrit.wikimedia.org/r/1008980

Change 1008982 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Move $recurringOptions calculation out of EmailForm

https://gerrit.wikimedia.org/r/1008982

@Ejegg the text change makes sense to me too, thanks

Hey @Ejegg @MSuijkerbuijk_WMF, for the landing page URL, it'd be neat to have it available by 03/13 if possible so I can update the email and pass it off to Technical QA. Thanks!

Change 1008974 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] New variant for recurring upgrade landing pages

https://gerrit.wikimedia.org/r/1008974

@Ejegg you mention a success page above. We are working on Thank You pages (old drafts) for this campaign, but I want to confirm if these are what you are referring to when you say success page, and if so if amount can be passed to it. Or is there going to be a different page in the environment you are developing?

Change 1009562 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Fix validation for amount

https://gerrit.wikimedia.org/r/1009562

@MSuijkerbuijk_WMF and @ppenloglou we have a simple success page as part of the flow that will have the amount and the next date on it. If you want to redirect the donor to another page, we could do that and put the date and the new amount on the URL. Or we could take the HTML you're working on and just use it to replace the simple page in the existing flow.

@ppenloglou if we do a redirect, what format would you like that date and amount in? Pre-formatted for the donor's locale, or YYYY-mm-dd format for the date and amount, currency, and locale as separate parameters?

@Ejegg do you have a link to see that flow? And I'm tagging @ehughes as she works on the TY pages (no Panos)
About the format, in my opinion we should follow the same as in the first landing page

@MSuijkerbuijk_WMF I'm waiting for review on some patches before I can deploy the version with the amount and next date. If we're going to see each other in a meeting later today I can demo it from my computer!

Change 1009569 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Add new amount and next date to upgrade success page

https://gerrit.wikimedia.org/r/1009569

Sounds good, thanks!

Oops, sorry for the mixup @ppenloglou. We're trying to get it deployed soon!

@ehughes how would you feel about keeping the thank you page in the flow? When we go multilingual it might be easier to keep translations and formatting in sync between the different pages that way. Or if you feel like it would be better on a different domain, please let me know what format you want all those parameters in.

@ehughes I was just in a meeting with @MSuijkerbuijk_WMF and she brought up the fact that the TY page can set cookies to hide banners, so I guess that makes it the better option.

If I send you the parameters like this, can you format them for display in Javascript? (replace UpgradeThankYou with whatever page title you end up using)

https://thankyou.wikipedia.org/wiki/UpgradeThankYou/en?next_date=2024-03-12&amount=12.50&currency=USD&country=US

And just to confirm, we will have the each translation as a /xx subpage as with the ThankYou pages?

Change 1009562 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Fix validation for amount

https://gerrit.wikimedia.org/r/1009562

Change 1009569 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Add new amount and next date to upgrade success page

https://gerrit.wikimedia.org/r/1009569

@Ejegg could you share the link with me for testing and @PPenloglou-WMF to add it to the email, please? Thanks

You can get links from a donor's CiviCRM contact summary page (I'm not pasting mine publicly as it'll let anyone reading this change my donation amount) on the right column in the 'Donor Prefs Links' section. The format will be:

https://donorpreferences.wikimedia.org/index.php?title=Special:RecurUpgrade/recurUpgrade&variant=v01&contact_id=CIDTOKENGOESHERE&checksum=CHECKSUMTOKENGOESHERE

and the format for the 'no, keep it the same' link would be the same, plus '&submit=cancel', like so:

https://donorpreferences.wikimedia.org/index.php?title=Special:RecurUpgrade/recurUpgrade&variant=v01&submit=cancel&contact_id=CIDTOKENGOESHERE&checksum=CHECKSUMTOKENGOESHERE

Hi @Ejegg

Flagging a couple of issues and questions:

• Is there a testing Contact ID for QA? We need to be able to QA the flow before the emailing (scheduled for March 20).

• We need clarity on this to finalised coding the email template. In emails, we usually see these codes below for contact ID. @PPenloglou-WMF needs a link that can be added to the email so that Acoustic pre-fills the Contact_ID and Checksum for each donor. Could you both sync on that?
  • contact_id=%%ContactID%%
  • contact_hash=%%contact_hash%%
  • checksum=????

To recap again:

• Yes CTA = takes you to the upgrading tool with amount choices and confirmation CTA (and also includes a CTA again with the option to 'No, thanks')

• No CTA = linked to the TY variant where we confirm no upgrade is done.

Thanks

@MSuijkerbuijk_WMF we don't have any company cards to test with, so when we QA things the testers just make a small donation (which Donor Relations can later refund), then use their own Civi record.

The Yes CTA link is the first one above, with CIDTOKENGOESHERE replaced with %%ContactID%% and CHECKSUMTOKENGOESHERE replaced with whatever token will put the checksum (not the hash!) in the email.

The No CTA link is the second one above, with the same substitutions.

Hey @Ejegg, just updated the email template hyperlinks as follows:

Yes Link:

https://donorpreferences.wikimedia.org/index.php?title=Special:RecurUpgrade/recurUpgrade&variant=v01&contact_id=%%ContactID%%&checksum=%%checksum%%&wmf_medium=email&wmf_campaign=C2324_UpgradeRecurring

No Link:

https://donorpreferences.wikimedia.org/index.php?title=Special:RecurUpgrade/recurUpgrade&variant=v01&submit=cancel&contact_id=%%ContactID%%&checksum=%%checksum%%&wmf_medium=email&wmf_campaign=C2324_UpgradeRecurring

Hi @Ejegg , I've attached a Zip with an updated CSS file with some fixes and overrides for the page appearance.
One thing I did notice is that the checkmark image is not showing up as Content Security Policy is blocking loading it in from donate wiki, I've added it to the zip, would you be able to upload it and update the link in the CSS? Its a background image in the rule for:

.recurUpgradeRadio input:checked + label::after

Thank you!

Change 1011175 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Update RecurUpgrade css

https://gerrit.wikimedia.org/r/1011175

Change 1011175 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Update RecurUpgrade css

https://gerrit.wikimedia.org/r/1011175

@ehughes thanks for the new CSS! I've just deployed it along with the uploaded image.

Thanks both, cross-posting from Slack. Great progress to finalise the adjustments (notes doc)

My only feedback is related to the mobile version where font sizes look too small and the footer could be pushed down. @ehughes and @spatton wonder what you think. Desktop looks good.

Hi @MSuijkerbuijk_WMF thanks for this. It's actually a problem with the donor preferences website not having the right tag to show the responsive CSS I included.

@Ejegg the meta viewport tag needs to be updated, is this possible? Currently its this, which is setting the viewport to 1000 pixels wide regardless of the size of the screen looking at it:

<meta name="viewport" content="width=1000">

But to render responsive CSS it should be something like the following:

<meta name="viewport" content="width=device-width, initial-scale=1">

I'm not sure what other pages use the email preferences header (changing it there would affect their layout) so it could be done via javascript just on this page, eg.

document.querySelector('meta[name="viewport"]').setAttribute("content", "width=device-width, initial-scale=1");

It'll probably be an improvement for the EmailPreferences page too! I'll see what the best way to change that in the rendered HTML is so we don't get a restyling flash when the JS runs.

Thanks, @Ejegg ! If the email preferences page needs some responsive CSS to fix it up after changing I'd be happy to take a look at that also.

Just to follow up, we were able to change the viewport in the rendered HTML, and that change went out today.