darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-05 15:58:25 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
d660db84b97b8743cf6fdd3f7e87faef69692a79
notifications-admin/app/templates/views/broadcast/preview-areas.html

72 lines
2.8 KiB
HTML
Raw Normal View History

Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{% extends "withnav_template.html" %}
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
{% from "components/button/macro.njk" import govukButton %}
{% from "components/page-header.html" import page_header %}
Add a key to the map To help people understand that broadcasting is not a precise technology, we have shown the estimate bleed area on the map. Because people aren’t familiar with the technology a visual only clue is not enough. So this commit adds a key to the map, which explains what the different outlines mean. It also removes the sticky footer from this page to: - make the key visible on the page - make people scroll and review the map before they get to the big green button - not reduce the size of the map any further
2020-08-26 10:43:55 +01:00
{% from "components/page-footer.html" import page_footer %}
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
{% from "views/broadcast/macros/area-map.html" import map %}
Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{% from "components/back-link/macro.njk" import govukBackLink %}
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
{% block service_page_title %}
Replace use of 'broadcast'
2021-07-05 15:57:37 +01:00
Choose where to send this alert
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
{% endblock %}
Add a map So you can check you’ve chosen the right areas, and to give you a clear idea of where the boundaries of an area are. The Javascript and CSS for the map is only loaded on this page because it adds quite a few kb, and we don’t want to be sending assets to the majority of our users who will never see them.
2020-07-06 10:53:14 +01:00
{% block extra_stylesheets %}
Move styling into separate files for reuse
2020-09-03 10:18:28 +01:00
{% include "views/broadcast/partials/area-map-stylesheets.html" %}
Add a map So you can check you’ve chosen the right areas, and to give you a clear idea of where the boundaries of an area are. The Javascript and CSS for the map is only loaded on this page because it adds quite a few kb, and we don’t want to be sending assets to the majority of our users who will never see them.
2020-07-06 10:53:14 +01:00
{% endblock %}
{% block extra_javascripts %}
Move styling into separate files for reuse
2020-09-03 10:18:28 +01:00
{% include "views/broadcast/partials/area-map-javascripts.html" %}
Add a map So you can check you’ve chosen the right areas, and to give you a clear idea of where the boundaries of an area are. The Javascript and CSS for the map is only loaded on this page because it adds quite a few kb, and we don’t want to be sending assets to the majority of our users who will never see them.
2020-07-06 10:53:14 +01:00
{% endblock %}
Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{% block backLink %}
{{ govukBackLink({ "href": back_link }) }}
{% endblock %}
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
{% block maincolumn_content %}
Move back link outside of main where it was used in the page header The page_header macro includes an optional back link. Since the page_header is always used inside `<main>`, where the back link should not be, this stops setting the back link in the page header and instead sets it in the new `backLink` block.
2021-07-30 18:23:12 +01:00
{{ page_header("Choose where to send this alert") }}
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
Make the broadcast flow talk to the API This commit removes the code the puts areas into the session and instead creates and then updates a draft broadcast in the database. This is so we can avoid session-related bugs, and potentially having a large session when we start adding personalisation etc. Once a broadcast is ready to go it is set to `broadcasting` straight away with no approval. We’ll revisit this as we learn more about how users might want to manage who can create and approve broadcasts. The tests are a bit light in terms of checking what’s on the page, but clicking through the pages is probably good enough for now.
2020-07-09 10:33:50 +01:00
{% for area in broadcast_message.areas %}
Style the area labels and polygons Gives them some colours, borders and stuff to make them visually consistent with the rest of Notify. The idea is the tags and polygons have a similar affordances (i.e. border thickness, colour) to visually link them and imply that they are two representations of the same thing.
2020-07-06 10:53:15 +01:00
{% if loop.first %}
<ul class="area-list">
{% endif %}
<li class="area-list-item">
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
{{ area.name }}
Make remove ('x') links buttons The text never had underlines like our other link-button components so always looked like buttons. If they look like buttons, they should act like them too and have those semantics. This give them a role of button and uses the class and data attribute for the button component from GOVUK Frontend to make them work like one. These changes include a fair amount of styles to override those the govuk-button class brings in. I've tried to mark those ones to at least make that obvious.
2021-10-22 11:54:41 +01:00
<a class="area-list-item-remove govuk-button" data-module="govuk-button" role="button" href="{{ url_for('.remove_broadcast_area', service_id=current_service.id, broadcast_message_id=broadcast_message.id, area_slug=area.id) }}">
Remove extra group from remove SVG The SVG used for the 'X' in the remove area button has 2 <g> (group) elements, one wrapping everything and one wrapping the two lines that make the cross. The first <g> isn't needed and means that the SVG ends up with 2 accessible names: 1. the <svg> element gets named with the text from the <title> because of it's aria-labelledby attribute referencing it 2. the first <g> gets named with the text from the <title> because the algorithm that gets the name looks for any descendent <title>s This removes the first <g> so only the accessible name for the <svg> gets announced.
2021-11-03 10:33:10 +00:00
<svg id="area-list-item-remove__icon" width="11" height="11" viewbox="0 0 10 10" aria-labelledby="area__{{ loop.index }}" role="img" xmlns="http://www.w3.org/2000/svg">
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
<title id="area__{{ loop.index }}">Remove {{ area.name }}</title>
Tweak spacing, size and hover state when focused The size and position of the 'X' has deviated a bit from the design intentions of the original. The original shared the x-height of the area text and has positioned to be vertically and horizontally centered. These changes assume an x-height of 11px and use flexbox to center the new 'X' horizontally and vertically. This also tweaks the visual state when focused and then hovered so matches other buttons without breaking the design.
2021-10-25 15:50:07 +01:00
<g transform="rotate(45),translate(1, -6)">
<line stroke-width="1.75" id="svg_1" y2="0" x2="6" y1="12" x1="6" stroke="currentColor" fill="none"/>
<line stroke-width="1.75" id="svg_3" y2="6" x2="0" y1="6" x1="12" stroke="currentColor" fill="none"/>
Replace 'x' psuedo element with SVG The current link button for removing an area is created using a psuedo element with an 'x' as content. The inline box for the 'x' overlapped its parent. This is visible in high contrast mode, breaking the parent's border. Despite existing in CSS, the 'x' is also announced by screen readers, which is not what we want. This changes it to be an inline SVG with a role of image. It doesn't require as large an inline box so doesn't cause visual issues in high contrast modes. It also means we can set it's label similar to how you would an image's alt text, giving us control over what is announced by screen readers. This commit also includes some extra CSS, targeting high contrast modes, giving the link button the following when viewed in those modes: - a complete border so it is distinguishable from the list item - a focus style
2021-10-21 13:26:40 +01:00
</g>
</svg>
</a>
Style the area labels and polygons Gives them some colours, borders and stuff to make them visually consistent with the rest of Notify. The idea is the tags and polygons have a similar affordances (i.e. border thickness, colour) to visually link them and imply that they are two representations of the same thing.
2020-07-06 10:53:15 +01:00
</li>
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
{% if loop.last %}
Fix spacing between button and selected areas Adding left margin to the button meant that when it wrapped onto a new line it didn’t align flush with the left edge of its containing column. Instead we can: - move the link outside the list (which is better semantically anyway) - then add the margin to the last item of the list (which is now the last selected area, not the link)
2020-08-18 09:51:52 +01:00
</ul>
Style the area labels and polygons Gives them some colours, borders and stuff to make them visually consistent with the rest of Notify. The idea is the tags and polygons have a similar affordances (i.e. border thickness, colour) to visually link them and imply that they are two representations of the same thing.
2020-07-06 10:53:15 +01:00
{{ govukButton({
"element": "a",
"text": "Add another area",
Make the broadcast flow talk to the API This commit removes the code the puts areas into the session and instead creates and then updates a draft broadcast in the database. This is so we can avoid session-related bugs, and potentially having a large session when we start adding personalisation etc. Once a broadcast is ready to go it is set to `broadcasting` straight away with no approval. We’ll revisit this as we learn more about how users might want to manage who can create and approve broadcasts. The tests are a bit light in terms of checking what’s on the page, but clicking through the pages is probably good enough for now.
2020-07-09 10:33:50 +01:00
"href": url_for('.choose_broadcast_library', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
Style the area labels and polygons Gives them some colours, borders and stuff to make them visually consistent with the rest of Notify. The idea is the tags and polygons have a similar affordances (i.e. border thickness, colour) to visually link them and imply that they are two representations of the same thing.
2020-07-06 10:53:15 +01:00
"classes": "govuk-button--secondary govuk-!-margin-bottom-5"
}) }}
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
{% endif %}
{% else %}
<p class="govuk-body">
{{ govukButton({
"element": "a",
"text": "Add broadcast areas",
Make the broadcast flow talk to the API This commit removes the code the puts areas into the session and instead creates and then updates a draft broadcast in the database. This is so we can avoid session-related bugs, and potentially having a large session when we start adding personalisation etc. Once a broadcast is ready to go it is set to `broadcasting` straight away with no approval. We’ll revisit this as we learn more about how users might want to manage who can create and approve broadcasts. The tests are a bit light in terms of checking what’s on the page, but clicking through the pages is probably good enough for now.
2020-07-09 10:33:50 +01:00
"href": url_for('.choose_broadcast_library', service_id=current_service.id, broadcast_message_id=broadcast_message.id),
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
"classes": "govuk-button--secondary"
}) }}
</p>
{% endfor %}
Make the broadcast flow talk to the API This commit removes the code the puts areas into the session and instead creates and then updates a draft broadcast in the database. This is so we can avoid session-related bugs, and potentially having a large session when we start adding personalisation etc. Once a broadcast is ready to go it is set to `broadcasting` straight away with no approval. We’ll revisit this as we learn more about how users might want to manage who can create and approve broadcasts. The tests are a bit light in terms of checking what’s on the page, but clicking through the pages is probably good enough for now.
2020-07-09 10:33:50 +01:00
{% if broadcast_message.areas %}
Add estimated areas for non-visual users Since the key relies on visual association between the shapes on the maps and the styling of the key, it won’t work for non-visual users. An alternative way of giving them the same information is by providing the size of the area numerically.
2020-09-08 16:35:03 +01:00
{{ map(broadcast_message) }}
Adjust spacing and border on details map We hide the map inside a details element. Because the map has such a strong shape I don’t think it needs the grey border to contain it. This commit removes the border, and adjusts the spacing to group things by proximity alone. By removing the border and associated gutter we can give more space to the map, and make the page look less busy.
2020-10-02 14:51:57 +01:00
<form action="{{ url_for('.preview_broadcast_message', service_id=current_service.id, broadcast_message_id=broadcast_message.id) }}" method="get" class="govuk-!-margin-top-1">
Update preview button content
2021-07-05 16:50:49 +01:00
{{ page_footer('Preview this alert') }}
Add some views for selecting broadcast areas These are just so we have some pages to click through for now. They don’t use real templates, or any of the broadcast stuff from the database. But I think it’s useful to get some skeleton pages in first so that we can see the map etc working in production, then build on that, without having to do it all in one mega PR. For that reason there are two short term things I’ve done in this commit which should be revisited soon: - no tests for the endpoints - data about which areas are selected is stored in the session
2020-07-06 10:53:14 +01:00
</form>
{% endif %}
{% endblock %}
Reference in New Issue Copy Permalink