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
6650e1663cdbbee71c03d0d666969eaa81fa0728
notifications-admin/app/templates/views/service-settings/estimate-usage.html

49 lines
1.7 KiB
HTML
Raw Normal View History

Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
{% extends "withnav_template.html" %}
Make answers to volume questions optional It’s annoying and very ‘computer says no’ to make people type `0` in a box. We can see from our analytics that this error is affecting about 7% of users trying to go live. This commit relaxes the validation to only require a number greater than 1 for at least one of the questions. It also lets people enter their numbers comma-separated – like our examples suggest – but normalises them to integers before sending them over to the API.
2019-02-15 13:34:29 +00:00
{% from "components/banner.html" import banner_wrapper %}
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% from "components/form.html" import form_wrapper %}
Add GOV.UK Design System style back links The Design System has standardised on back links being at the top of the page, decorated with a small text-coloured arrow. I think this makes more sense than having them at the bottom, because it suggests, in some way, being able to go back before commiting to any of the forms on the page. Whereas the things at the bottom of the page should be performing actions on what’s in the page. The reason for making this change now is that it de-clutters the area around the green buttons. This was presenting a design challenge where multiple levels of interaction were happening in the same form. Moving these back links to the top of the page should mean that, in these complicated forms, there’s one fewer thing to compete for the user’s attention. I’ve componentised this into a `page_header` macro so that the change is easier to roll out and maintain.
2019-04-29 11:44:05 +01:00
{% from "components/page-header.html" import page_header %}
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
{% from "components/page-footer.html" import page_footer %}
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 %}
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
{% block service_page_title %}
Add latest content From: https://docs.google.com/document/d/1aykf1MjJH5y21Bz1ht6WJncb9cKu0fsPlac3-bkMPe8/edit
2019-02-27 13:02:37 +00:00
Tell us how many messages you expect to send
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00: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.request_to_go_live', service_id=current_service.id) }) }}
{% endblock %}
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
{% block maincolumn_content %}
Replace `grid-row` with `govuk-grid-row` Replaced all instances of `grid-row` in the HTML and JavaScript with `govuk-grid-row`, which is the new GOV.UK Frontend class.
2020-02-19 11:57:15 +00:00
<div class="govuk-grid-row">
Replace the `.column-...` classes in _grids.scss We had 7 classes in _grids.scss named `.column-...` which were being used to give a certain column width. These worked by using `@include grid column()`, which is now deprecated. `.column-whole` and `.column-three-quarters` can be removed and replaced with `govuk-grid-column-full` and `govuk-grid-column-three-quarters` respectively. The other column classes don't have a direct replacment in GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width` SASS map in `extensions.scss` to add in extra widths, then use this with the `govuk-grid-column` mixin to create new classes in for our custom widths in `_grids.scss`
2020-02-20 16:55:56 +00:00
<div class="govuk-grid-column-full">
Make answers to volume questions optional It’s annoying and very ‘computer says no’ to make people type `0` in a box. We can see from our analytics that this error is affecting about 7% of users trying to go live. This commit relaxes the validation to only require a number greater than 1 for at least one of the questions. It also lets people enter their numbers comma-separated – like our examples suggest – but normalises them to integers before sending them over to the API.
2019-02-15 13:34:29 +00:00
{% if not form.at_least_one_volume_filled %}
{% call banner_wrapper(type='dangerous') %}
<h1 class='banner-title'>
Add latest content From: https://docs.google.com/document/d/1aykf1MjJH5y21Bz1ht6WJncb9cKu0fsPlac3-bkMPe8/edit
2019-02-27 13:02:37 +00:00
Enter the number of messages you expect to send in the next year
Make answers to volume questions optional It’s annoying and very ‘computer says no’ to make people type `0` in a box. We can see from our analytics that this error is affecting about 7% of users trying to go live. This commit relaxes the validation to only require a number greater than 1 for at least one of the questions. It also lets people enter their numbers comma-separated – like our examples suggest – but normalises them to integers before sending them over to the API.
2019-02-15 13:34:29 +00:00
</h1>
{% endcall %}
{% else %}
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('Tell us how many messages you expect to send') }}
Make answers to volume questions optional It’s annoying and very ‘computer says no’ to make people type `0` in a box. We can see from our analytics that this error is affecting about 7% of users trying to go live. This commit relaxes the validation to only require a number greater than 1 for at least one of the questions. It also lets people enter their numbers comma-separated – like our examples suggest – but normalises them to integers before sending them over to the API.
2019-02-15 13:34:29 +00:00
{% endif %}
{% call form_wrapper() %}
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
<div class="form-group">
Update ForgivingIntegerField Makes it inherit from GovukTextInputField. Changes to govuk_field_widget to allow the value attribute to be set by passing a value keyword argument to the __call__ method. Includes changes to templates that use this form and associated tests.
2020-08-07 11:36:45 +01:00
{{ form.volume_email(param_extensions={
"classes": "govuk-!-width-one-half",
"hint": {"text": "For example, 50,000"},
}) }}
{{ form.volume_sms(param_extensions={
"classes": "govuk-!-width-one-half",
"hint": {"text": "For example, 50,000"},
}) }}
{{ form.volume_letter(param_extensions={
"classes": "govuk-!-width-one-half",
"hint": {"text": "For example, 50,000"},
}) }}
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
</div>
Convert radios on research consent (basic)
2020-06-26 21:56:08 +01:00
{{ form.consent_to_research }}
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
{{ page_footer('Continue') }}
Use a macro for form tags This will stop us repeatedly forgetting to add `novalidate` and `autocomplete='off'` to our forms (which is how most of them are set up). It uses sensible defaults, based on how we most-commonly configure forms: - most of our forms are `post`ed (but this can be overridden) - `autocomplete` should only be enabled where it makes sense, otherwise it’s more annoying than useful (but this can be overriden) - we should never be using HTML5 form validation because our own error styles and messages are better
2018-09-19 12:39:36 +01:00
{% endcall %}
Move the ‘estimated usage’ questions We get a bunch of requests to go live where people have told us they're going to send email but there is no email reply-to address present. These come from 2 scenarios: 1. when there are email templates, and no reply to address – but they ignore the checklist 2. when there are no email templates (yet) but they provide anticipated volumes for email At the moment we only auto-check for a reply to address when they have email templates. And because the question about anticipated volumes follows the checklist, you'll get a checklist that passes (reply addresses not required as no templates present) - but your future intent that differs (reply address IS required because you have anticipated volumes). So let’s bring the request for anticipated volumes into the checklist, that way we can dynamically add the requirement for a reply to address if they say they will send email but don't have templates yet. We should begin storing it in the database against the service to stop people having to re-enter it each time they try to complete the go live screens. This also means moving the ‘consent to research question’ along with the questions about volume, because - we want people to answer both before going live - we don’t want to clutter up the summary page by asking questions there too
2019-02-15 11:03:19 +00:00
</div>
</div>
Split into two pages A lot of users aren’t reading or paying attention to the checklist on the request to go live page. We think that we can get more people to read it by putting it on its own page, where users won’t jump straight to filling in the form. This will, later on, let us make this page smarter by automatically detecting if they’ve done the necessary things.
2018-02-20 12:15:35 +00:00
{% endblock %}
Reference in New Issue Copy Permalink