Email templates redesign

[devmount]

What changed?

This change implements changes to all email templates after the redesign:

• confirm.jinja2 (email to subscriber holding confirm and reject buttons)
• pending.jinja2 (email to potential attendee informing that the subscriber decision on the booking is pending)
• invite.jinja2 (email to attendee after confirmation)
• rejected.jinja2 (email to attendee after rejection)
• cancelled.jinja2 (email to attendee when subscriber cancelled an already confirmed booking)

Why?

Consistency and a common design language not only on application level, but also for external communication.

How to test

Basically triggering every email type from the 5 above and compare to the designs.

1. Make a booking: Check the confirmation and pending mails
2. Accept a booking: Check the accepted email
3. Decline a booking: Check the declined email
4. Cancel a booking from the bookings page: Check the cancelled email

Limitations and Notes

• The new designs introduced new data shown in the emails, as well as status icons and new layouts, so I needed to extend our existing email controller code quite a lot.
• We currently don't have a way to name/rename bookings, so I used the schedule name for now
• We currently don't have a way to add a decline note, so I skipped that for now
• Contribution and support footer links are hard-coded for now. We can move them to an env if needed in the future.

Applicable Issues

Closes #1378

Screenshots

As an example here the booking confirmation mail to the subscriber (Desktop and mobile):

Before:

After

[davinotdavid]

Nice, great work so far! Thanks for tackling this issue.

I believe we still need to polish a bit on the UI details side comparing with the Zeplin mockups as there are some divergences:

[Host - Confirmation needed]

• Title font-weight is 700 vs 600 from the design
• Schedule title font-size is 16px vs 1.25 rem / 20px from the design
• Schedule title font-weight is 700 vs 600 from the design
• Schedule title margin-bottom is 8px vs 0.25 rem / 4px from the design
• Date/Time/Timezone font-weight is 700 vs normal from the design
• Date/Time/Timezone margin-bottom is 5px vs 0.25 rem / 4px from the design
• Time badge font-size is 9px vs 0.625 rem / 10px from the design
• "Meeting with" font-size is 11px & 13px vs 0.875 rem / 14px from the design
• "Meeting with" margin-bottom is 12px vs 1 rem / 16px from the design
• "Open in Thunderbird Appointment" font-size is 12px vs 0.813 / 13px from the design
• The Decline / Confirm buttons are flipped

[Footer]

• The gap / margin between the footer links and the footer blob ("Thunderbird is part...") seems wider than in the design. Can we confirm that?
• The footer links changed colours after a design revision in Zeplin
• The text MZLA Technologies Corporation should be a link to https://blog.thunderbird.net/2020/01/thunderbirds-new-home/
• It seems that the new design revision got rid of the max-width: 328px in the blob
• The text in the badges of "confirmed" / "declined" / "cancelled" seem not centralized or with uneven vertical padding too

These notes are not 100% comprehensive as there are very similar divergences in the other layouts too so I'd suggest a UI pass on it just to make sure that it's aligned. Thanks!

[devmount]

@davinotdavid Thanks so much for your thorough review! I was already looking forward to it, it's much appreciated that you look at all the details!

It seems the badges and other parts got a lot of changes in the designs since I first implemented it. I hope I caught everything. Let me know if there's still inconsistencies!

[davinotdavid]

@devmount Thanks for the revision! We're close! There are a few things to update.

I didn't duplicate notes in between templates but some of them apply to all templates. For example, the confirmed / declined / pending badge spacing, the spacing in the footer, the line-height, etc.

[Host - Confirm / Decline Template]

[Bookee - Pending Template]

[Bookee - Confirmed Template]

Let me know if you have any questions!

[devmount]

@kewisch @davinotdavid Thanks both of you. Regarding text-underline-offset: This shouldn't be an issue if some platforms don't support it. Since we're using normal a tags, those would show underlined anyway, so this should be a graceful fallback for that specific case.

[kewisch]

I see some minor (though noticeable) issue with spacing:

• The space between the icon and "30 Minutes" is missing on Gmail
• Apple Mail seems to not center the CONFIRMED label

For Thunderbird Desktop, maybe it is an issue with attachment types or remote images? I'm not sure how compatible it would be, but potentially you could use a data url. I find displaying images across clients is most tricky.

check-circle-error also looks a bit smaller than the others. Do reach out to design in case you need updated graphics.

[devmount]

@kewisch Thanks so much for your suggestions! Replacing the inline images with data URLs is a great call IMHO, since this reduces unnecessary attachment bloat. What I did now:

• Replaced all icons and the Logo with a base64 data URL (this also reduced the controller code a lot since we now only have to add the invite ics file as actual attachment)
• Replaced the flex gap with a right margin, since this might have better support with most of email parsers

@davinotdavid Could you test this again with the different email providers? I don't have the possibility to test with Apple mail atm.

[davinotdavid]

@devmount @kewisch Hmm now we have some reversed behavior between TB Desktop <-> Gmail. It seems that Gmail strictly blocks embedded images for security reasons. Here are some screenshots:

Thundermail's Webmail:

--

TB Desktop (now show images!):

--

Apple Mail (1px ish misalignment of the "pending" text within the badge):

--

Gmail (doesn't show images anymore):

[devmount]

@davinotdavid Ah dang, looking great on Thundermail and TB Desktop now, but not on gmail 😅 What do we do? I can investigate gmail inline images, maybe I can find something

[davinotdavid]

@devmount there's quite a few people with the same problem online that have approached this with different techniques and varying results but it seems that people either:

• Add images as Content ID / CID
• Host images externally / serve through HTTPS
• Embed in CSS (using background image + base64) instead of img src=""

We didn't seem to have this problem in the previous templates though

[devmount]

@davinotdavid In the previous templates we used CID, that's why they were working. We can always revert back to it. But we could try the CSS background (seems like a low-effort workaround to test) first?

[davinotdavid]

@devmount sure yeah, try them out!

[devmount]

@davinotdavid Alright will do. And thanks so much for testing again and again, Davi! The helps a lot!

[devmount]

@davinotdavid I tried with background-image now. Would be awesome if you could test again 🙏🏻 When it's not working, happy to revert back.

[davinotdavid]

@devmount just tested, not fixed unfortunately. Now it doesn't show the images nor the alt text for them:

All the other clients are the same / load correctly. Since Gmail is so prevalent, we should probably fix this somehow. I don't know how to fix this from the top of my head so it requires a bit of research on what is best.

[devmount]

@davinotdavid Thank you. I'll investigate some more for the gmail images display issues before reverting. I'll report back.

[devmount]

@davinotdavid After some digging, I think we have the following options:

1. Revert to CID attachments (images are real attachments again referenced via cid in <img src=...>). Confirmed working, but there was an issue in the Thunderbird desktop client, right? Do we know if this was related to local settings?
2. Serve images from a public HTTPS URL (images are in the public/no auth dir and referenced via <img src="https://...">. This should work in Gmail via their image proxy. But I expect most clients show an 'images blocked, click to display' banner by default (including Thunderbird desktop). Also when reading through articles, this seems to be the default way to embed images in emails.

Ruled out:

• Data Urls (not supported by gmail)
• Inline SVGs (not supported by most platforms)
• Icon webfonts (not supported by most platforms)

[kewisch]

If CID images are what others are using and ours is the only one that is not then that seems like the most viable path. Maybe we can get some help from the Desktop team as to why they are not displayed. Possibly has to do with the order of mime multiparts?

[devmount]

@kewisch @davinotdavid Found it! It was a 2 line fix, but that bug was a nasty one 😅 We were accessing the message payload at index 1 within the for loop, but the contents at that index changed because we called add_attachment() in a previous run of the for loop. The fix was to get the payload before we even start the loop.

So it was our fault (that bug was there for since we first implemented the emails, but it never occured to us until we added further attachments with the icons). Interesting though that the other email platforms were somehow able to still map the attachments to the correct files.

[davinotdavid]

@devmount can confirm that images works well in TB Desktop, Thundermail Webmail, Gmail and Apple Mail! Thanks for the fix 🎉

I hope you don't mind but I've noticed some small inconsistencies around vertical alignment and spacing which got me into a rabbit hole 😅 Seems like flex / grid has some issues where some properties gets stripped out in some clients (for example Gmail was keeping the display:inline-flex but removing the align-items:center, seems to be a common issue).

Here's all updated screenshots which IMHO is perhaps as good as it gets. There's a 1px vertical misalignment in Apple Mail on the badge text which is bothering me but I've spent too much time chasing this 1px while not breaking the rest which makes me think that it is fine.

Gmail

[Pending]

[Confirmed]

[Cancelled]

[Declined]

TB Desktop

[Pending]

[Confirmed]

[Cancelled]

[Declined]

Apple Mail

[Pending]

[Confirmed]

[Cancelled]

[Declined]

Thundermail Webmail

[Pending]

[Confirmed]

[Cancelled]

[Declined]

[devmount]

@davinotdavid

I hope you don't mind...

Of course I don't! Thanks so much for further improving this and also testing on every platform 👍🏻 This is so helpful. Looking great now! I think this PR is finally ready to be merged, or is there something else still open?