Files
notifications-admin/app/templates/views/edit-sms-template.html

55 lines
2.1 KiB
HTML
Raw Normal View History

2015-12-14 16:53:07 +00:00
{% extends "withnav_template.html" %}
{% from "components/textbox.html" import textbox %}
{% from "components/page-header.html" import page_header %}
{% from "components/page-footer.html" import page_footer %}
{% from "components/form.html" import form_wrapper %}
{% block service_page_title %}
{{ heading_action }} text message template
{% endblock %}
2015-12-14 16:53:07 +00:00
{% block maincolumn_content %}
{{ page_header(
'{} text message template'.format(heading_action),
back_link=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)
) }}
{% call form_wrapper() %}
<div class="govuk-grid-row">
<div class="govuk-grid-column-two-thirds">
{{ form.name(param_extensions={
"classes": "govuk-!-width-full",
"hint": {"text": "Your recipients will not see this"}
}) }}
{{ textbox(
form.template_content,
highlight_placeholders=True,
width='1-1',
rows=5,
extra_form_group_classes='govuk-!-margin-bottom-2'
) }}
{% if current_user.platform_admin %}
{{ form.process_type }}
{% endif %}
</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='sms') }}" aria-live="polite">
&nbsp;
2021-01-08 12:48:42 +00:00
</div>
</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') }}
</div>
<aside class="govuk-grid-column-full">
{% include "partials/templates/guidance-personalisation.html" %}
{% include "partials/templates/guidance-optional-content.html" %}
{% include "partials/templates/guidance-links.html" %}
{% include "partials/templates/guidance-character-count.html" %}
</aside>
</div>
{% endcall %}
{% endblock %}