darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-16 20:49:00 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
52c9cf3e76a7fa10491cc1811dcd4ee9fbbd5f07
notifications-admin/app/templates/views/broadcast/preview-message.html

47 lines
1.3 KiB
HTML
Raw Normal View History

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/form.html" import form_wrapper %}
{% from "components/page-header.html" import page_header %}
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
{% from "components/page-footer.html" import page_footer %}
{% from "components/radios.html" import radio_select %}
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
{% extends "withnav_template.html" %}
{% block service_page_title %}
Preview message
{% endblock %}
{% block maincolumn_content %}
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
{{ page_header("Preview", back_link=url_for('.preview_broadcast_areas', 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
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 %}
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.first %}
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
<ul class="area-list">
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 %}
Add style for areas once selected Just having them in the boxes with the 2px black border made them look too much like textboxes.
2020-07-08 17:41:20 +01:00
<li class="area-list-item area-list-item--unremoveable">
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
{{ area.name }}
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
</li>
{% if loop.last %}
</ul>
{% endif %}
{% 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
{{ broadcast_message.template|string }}
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
{% call form_wrapper() %}
Make start time explicit when previewing a broadcast We recently introduced a form control that lets user choose when a broadcast ends. Based on the most recent research participant, we think: - there is a specific misunderstanding of what this control does - there is a general low level of understanding of what a ‘broadcast’ means People will try to understand what a ‘broadcast’ is by using mental models they have for other kinds of messaging, for example text messages. Other kinds of messaging are one-to-one, i.e. they go from a sender to a recipient. They are not ongoing in any way. Emails and texts are sent at a time (and for all practicable purposes are received at that same time). So, when we present the user with a form that controls time, they might well assume it controls the time when the message will be sent. This is a feature we offer for sending messages using a spreadsheet, and that’s where we’ve borrowed this pattern from. We reinforce this assumption with the labelling of the form control. By front-loading it with the word ‘When’ we are playing to the users confirmation bias, i.e. they are interpreting the meaning of the control in a way that confirms their prior beliefs about how messaging works. So this commit does two things: - re-labels the form to front-load the word ‘End’ not ‘When’ - adds text to the page explaining when the broadcast will start, so there’s a chance of overriding that confirmation bias If we can get users to go through this before sending a broadcast for real, it could help them learn what a broadcast is, and how it differs from sending text messages.
2020-07-27 17:25:13 +01:00
<h3 class="govuk-heading-s govuk-!-margin-top-6 govuk-!-margin-bottom-1">
Start time
</h3>
<p class="govuk-body govuk-!-margin-bottom-4">
Your broadcast will start when it’s approved by another member of your team.
</p>
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
{{ radio_select(
form.finishes_at,
Make start time explicit when previewing a broadcast We recently introduced a form control that lets user choose when a broadcast ends. Based on the most recent research participant, we think: - there is a specific misunderstanding of what this control does - there is a general low level of understanding of what a ‘broadcast’ means People will try to understand what a ‘broadcast’ is by using mental models they have for other kinds of messaging, for example text messages. Other kinds of messaging are one-to-one, i.e. they go from a sender to a recipient. They are not ongoing in any way. Emails and texts are sent at a time (and for all practicable purposes are received at that same time). So, when we present the user with a form that controls time, they might well assume it controls the time when the message will be sent. This is a feature we offer for sending messages using a spreadsheet, and that’s where we’ve borrowed this pattern from. We reinforce this assumption with the labelling of the form control. By front-loading it with the word ‘When’ we are playing to the users confirmation bias, i.e. they are interpreting the meaning of the control in a way that confirms their prior beliefs about how messaging works. So this commit does two things: - re-labels the form to front-load the word ‘End’ not ‘When’ - adds text to the page explaining when the broadcast will start, so there’s a chance of overriding that confirmation bias If we can get users to go through this before sending a broadcast for real, it could help them learn what a broadcast is, and how it differs from sending text messages.
2020-07-27 17:25:13 +01:00
show_now_as_default=False,
bold_legend=True
Let users choose when to end a broadcast Different emergencies will need broadcasts to last for a variable amount of time. We give users some control over this by letting them stop a broadcast early. But we should also let them set a maximum broadcast time, for: - when the duration of the danger is known - when the broadcast has been live long enough to alert everyone who needs to know about it This code re-uses the pattern for scheduling jobs, which has some constraints that are probably OK for now: - end time is limited to an hour - longest duration is 3 whole days (eg if you start broadcasting Friday you have the choice of Saturday, Sunday and all of Monday, up to midnight)
2020-07-16 10:49:21 +01:00
) }}
{{ page_footer('Submit for approval') }}
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
{% endcall %}
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 %}
Reference in New Issue Copy Permalink