Skip to content

[TWE-661] Add sticky call to action and new link type for all call to actions #402

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

Open
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

damwaingames
Copy link

@damwaingames damwaingames commented Aug 1, 2025

https://torchbox.atlassian.net/browse/TWE-661

Description of Changes Made

A new type of block has been created that is available on any page. It is called a Sticky Call To Action. This creates a small div that floats at the bottom right of the viewport and provides a link based on the same link types as the other Call To Actions.

An additional link type has been created called a Modal iframe, it opens a new modal window with an iframe displaying the contents of the URL that the link is set to. This is intended for use with pipedrive forms but in theory anything that you wanted iframing could be used.

The modal is created using the micromodal package and is as simplistic as possible. It has been added to the two existing CTA templates as well as the new sticky CTA template.

How to Test

On a page you want to add a sticky call to action, you can add a new block, and grouped with the other call to actions you will find the sticky call to action. Add it to the page and enter the text, subtext and choose a link type for the button. The text will be displayed in a bolder weight, the sub text will be displayed in a lighter weight on the line underneath.

The modal iframe link type is now available on all call to action blocks. Once selected it looks like any other external link field, but the contents of the external link will be displayed in an iframe on a modal dialog when the link is clicked.

Screenshots

Screenshot 2025-08-01 at 10 46 25 Screenshot 2025-08-01 at 10 47 55 Screenshot 2025-08-01 at 10 49 15 Screenshot 2025-08-01 at 10 50 04

MR Checklist

  • Add a description of your pull request and instructions for the reviewer to verify your work.
  • If your pull request is for a specific ticket, link to it in the description.
  • Stay on point and keep it small so the merge request can be easily reviewed.
  • Tests and linting passes.

Unit tests

  • Not required

Documentation

Browser testing

  • I have tested in the following browsers and environments (edit the list as required)
    • Latest version of Chrome on mac
    • Latest version of Firefox on mac
    • Latest version of Safari on mac
    • Safari on last two versions of iOS
    • Chrome on last two versions of Android

Data protection

  • Not relevant

Light and dark mode

  • I have tested the changes in both light and dark mode

Accessibility

  • Automated WCAG 2.1 tests pass
  • HTML validation passes
  • Manual WCAG 2.1 tests completed
  • I have tested in a screen reader
  • I have tested in high-contrast mode
  • Any animations removed for prefers-reduced-motion

Sustainability

  • Performance and transfer of data considered
  • If JavaScript is needed alternatives have been considered

Pattern library

  • The pattern library component for this template displays correctly, and does not break parent templates
  • The styleguide is updated if relevant

Copy link
Collaborator

@nickmoreton nickmoreton left a comment

Choose a reason for hiding this comment

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

I'm happy that the backend changes are good to go and it can be deployed to staging.

Because of the extensive frontend changes I would need to spend more time looking at those changes but that shouldn't hold up the staging testing, it seems to work as expected. If there are other frontend changes needed it's likely to be around how a frontend developer would implement this work.

Ideally a frontend developer should code review this too.

Copy link
Collaborator

@albinazs albinazs left a comment

Choose a reason for hiding this comment

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

Thank you, @damwaingames - this looks solid overall. There are a few bugs to address, and one product question: do we really need to support multiple modals with iframes on a single page? If yes, we should give it a proper accessibility/keyboard test pass after fixing the issues.

</header>
<main class="modal__content" id="filters-content">
<iframe
src="{{ cta.value.get_button_link }}"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Bug: should use value instead of cta.value, otherwise we have an empty iframe


{% if value.get_button_link_block.block_type == "modal_iframe" %}
<!-- Modal content -->
<div class="modal" id="iframe-embed-modal" aria-hidden="true">
Copy link
Collaborator

Choose a reason for hiding this comment

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

Bug: should use unique IDs if we want to support multiple modals on the page. Otherwise, multiple modals with iframes won't work as expected.

<div class="modal__overlay" data-micromodal-close></div>
<div class="modal__container" role="dialog" aria-modal="true" aria-labelledby="modal-title" >
<header class="modal__header">
<h2 class="modal__heading heading heading--two" id="modal-title">Service Enquiry</h2>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: should we make the modal title configurable instead of hard-coding it? Especially important if we want to support multiple modals on the page

{% endif %}
</div>
</div>

{% if value.get_button_link_block.block_type == "modal_iframe" %}
<!-- Modal content -->
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: can we create a separate reusable modal component for maintainability? It's the same in all 3 cases.

@@ -0,0 +1,14 @@
<button class="icon-button{% if modifier %} icon-button--{{ modifier }}{% endif %}{% if inverse %} icon-button--inverse{% endif %}{% if hidden %} hidden{% endif %}" {% if modifier and name %}data-{{ name }}-{{ modifier }}{% endif %}{% if data %} {{ data }}{% endif %}{% if aria %} {{ aria }}{% endif %}>
<span class="u-sr-only">
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: This seems to be redundant as we already have an aria attribute on the button.
For the modal, we pass "Close modal" as an aria label, and we also pass "close" as a modifier, so the screen reader will announce both of these.
Also, names of the icons are usually not descriptive enough to act as proper labels for screen reader users.

<header class="modal__header">
<h2 class="modal__heading heading heading--two" id="modal-title">Service Enquiry</h2>
<div class="modal__close">
{% include "patterns/atoms/icon_buttons/icon_button.html" with modifier="close" data="data-micromodal-close" aria='aria-label="Close modal"' %}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Bug: It looks like we don't have an icon with the name "close", so nothing is being rendered here. We could either use an existing icon from the sprites file, or add a new one

// <main class="modal__content" id="filters-content">
// Content
// </main>
// <footer class="modal__footer">
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: remove the modal footer as we don't have it in our implementation.
We can probably refer to the markup from dev tools, as currently we have a few more discrepancies, like aria-hidden="true" on modal, Django inclusion tag, etc.

left: 0;
right: 0;
bottom: 0;
// background-color: var(--color--background--overlay);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: can we please remove all commented-out unused CSS?


&[aria-hidden='false'] {
#{$root}__overlay {
animation: mmfadeIn 0.3s cubic-bezier(0, 0, 0.2, 1);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: we try to avoid keyframe animations unless absolutely necessary for performance reasons.
Can we use GPU-friendly transform/opacity with our $transition or $transition-quick variables?

@@ -370,6 +371,13 @@ $grid: 30px;
$grid-gutters: $grid;
$grid-gutters-large: 80px;
$grid-gutters-x-large: 120px;
$grid-xs: calc($grid / 4); // 5px
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggestion: We already have spacing variables, $spacer-[x].
Can we remove these new ones for maintainability? If a specific size we need to use frequently is missing, can we just add it to the list of the existing spacing vars?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants