darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-15 07:18:58 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
3c778de760e4858dd7abf15b00a86cdff599d190
notifications-admin/app/templates/views/edit-broadcast-template.html

51 lines
1.7 KiB
HTML
Raw Normal View History

Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +01:00
{% extends "withnav_template.html" %}
{% from "components/textbox.html" import textbox %}
{% from "components/page-header.html" import page_header %}
Make sticky footer take up full width So that we have space to display the message about how long the template content is alongside the button, without the message wrapping.
2021-01-06 16:57:57 +00:00
{% from "components/page-footer.html" import page_footer %}
Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +01:00
{% from "components/form.html" import form_wrapper %}
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 %}
Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +01:00
{% block service_page_title %}
Change page title on new broadcast template page Since broadcast services can only have one type of template we probably don’t need to disambiguate what kind of template you’re creating. And you’ve just come from a page where the button says ‘New template’, without the choice of radios after, so it’s nice for the page title to match that.
2020-08-17 13:01:33 +01:00
{{ heading_action }} template
Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +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": url_for('main.view_template', service_id=current_service.id, template_id=template.id) if template else url_for('main.choose_template', service_id=current_service.id, template_folder_id=template_folder_id)
}) }}
{% endblock %}
Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +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('{} template'.format(heading_action)) }}
Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +01:00
{% call form_wrapper() %}
<div class="govuk-grid-row">
<div class="govuk-grid-column-two-thirds">
Convert BaseTemplateForm to use new fields Updates StringField to GovukTextInputField. These changes also affect the following forms that inherit from BaseTemplateForm: - SMSTemplateForm - EmailTemplateForm Includes changes to templates that use these forms and associated tests.
2020-08-07 12:07:16 +01:00
{{ form.name(param_extensions={
"classes": "govuk-!-width-full",
"hint": {"text": "Your recipients will not see this"},
}) }}
Move message length information before the button We feel that this is more appropriate because it’s part of the information you’re agreeing to before you hit submit. Sometimes users can missing information that doesn’t start left-aligned to the column they’re interacting with. It also makes it closer to the Design System component. We’re keeping it in the sticky footer, so that it’s always visible no matter where in the message you’re scrolled to (this means you won’t have to edited to content then scroll down to check whether you’ve made it fit).
2021-01-08 13:49:18 +00:00
{{ textbox(
form.template_content,
highlight_placeholders=False,
autosize=True,
width='1-1',
rows=5,
extra_form_group_classes='govuk-!-margin-bottom-2'
) }}
Make sticky footer take up full width So that we have space to display the message about how long the template content is alongside the button, without the message wrapping.
2021-01-06 16:57:57 +00:00
</div>
<div class="govuk-grid-column-full">
Stop content length message from making page jumpy The content length message was making the page jumpy and causing reflows in three ways. This commit addresses each of those ways: As the user scrolled --- The footer went from fixed to sticky and the spacing around the message changed. This change in spacing was needed so that the message looked right in both contexts. I think the best way to resolve this is to not use the sticky footer when editing text message or broadcast templates. On my 1440×900 screen I can fit a 5 fragment text message, plus the ‘will be charged as 5 text messages’ message, plus the save button. Our top 10 screen resolutions according to our analytics are: Position | Resolution | Percentage of users ---------|------------|-------------------- 1 | 1920x1080 | 27.37% 2 | 1280×720 | 11.07% 3 | 1366×768 | 8.88% 4 | 1536×864 | 5.79% 5 | 1440×900 | 4.52% 6 | 1600×900 | 3.71% 7 | 1280×1024 | 3.10% 8 | 1680×1050 | 2.42% 9 | 1920×1200 | 2.33% 10 | 2560×1440 | 1.99% When the page first loaded --- The message is empty so takes up no space, then the javascript fires and inserts the message, taking up a line of space. This is resolved by making the empty message take up space with a non-breaking space character. When the user first typed --- We previously didn’t show any message until the user started typing. This meant that, with the above fix, there was a larger than normal empty space between the textarea and the save button. This is resolved by always showing the message, even when the user hasn’t typed anything yet. *** These are design decisions which made sense when the message was displayed along side the button, but we’ve had to change now that the message is above the button.
2021-01-08 15:23:54 +00:00
<div class="template-content-count">
<div data-module="update-status" data-target="template_content" data-updates-url="{{ url_for('.count_content_length', service_id=current_service.id, template_type='broadcast') }}" aria-live="polite">
&nbsp;
Use <div> for block level content
2021-01-08 12:48:42 +00:00
</div>
Make sticky footer take up full width So that we have space to display the message about how long the template content is alongside the button, without the message wrapping.
2021-01-06 16:57:57 +00:00
</div>
Stop content length message from making page jumpy The content length message was making the page jumpy and causing reflows in three ways. This commit addresses each of those ways: As the user scrolled --- The footer went from fixed to sticky and the spacing around the message changed. This change in spacing was needed so that the message looked right in both contexts. I think the best way to resolve this is to not use the sticky footer when editing text message or broadcast templates. On my 1440×900 screen I can fit a 5 fragment text message, plus the ‘will be charged as 5 text messages’ message, plus the save button. Our top 10 screen resolutions according to our analytics are: Position | Resolution | Percentage of users ---------|------------|-------------------- 1 | 1920x1080 | 27.37% 2 | 1280×720 | 11.07% 3 | 1366×768 | 8.88% 4 | 1536×864 | 5.79% 5 | 1440×900 | 4.52% 6 | 1600×900 | 3.71% 7 | 1280×1024 | 3.10% 8 | 1680×1050 | 2.42% 9 | 1920×1200 | 2.33% 10 | 2560×1440 | 1.99% When the page first loaded --- The message is empty so takes up no space, then the javascript fires and inserts the message, taking up a line of space. This is resolved by making the empty message take up space with a non-breaking space character. When the user first typed --- We previously didn’t show any message until the user started typing. This meant that, with the above fix, there was a larger than normal empty space between the textarea and the save button. This is resolved by always showing the message, even when the user hasn’t typed anything yet. *** These are design decisions which made sense when the message was displayed along side the button, but we’ve had to change now that the message is above the button.
2021-01-08 15:23:54 +00:00
{{ page_footer('Save') }}
Allow adding broadcast templates At the moment the page is the same as for text message templates, except: - different H1 - no guidance about personalisation, links, etc (until we decide how these should work) For now you won’t be able to really create a broadcast template, because the API doesn’t support it (the API will respond with a 400). But that’s OK because no real services have the broadcast permission yet. This required a bit of refactoring of how we check which template types a service can use, because there were some hard-coded assumptions about emails and text messages.
2020-07-01 16:43:08 +01:00
</div>
</div>
{% endcall %}
{% endblock %}
Reference in New Issue Copy Permalink