darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-08 17:23:13 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
a6c2b5a99cd2e8f8cfba3efafb99f30e4fae5f85
notifications-admin/app/templates/views/service-settings/request-to-go-live.html

81 lines
3.0 KiB
HTML
Raw Normal View History

Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions.
2016-01-07 12:29:56 +00:00
{% extends "withnav_template.html" %}
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/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 %}
Rename `submit_form` component to `page_footer` Submit form was - a confusing name in itself - not descriptive, because it also has an optional ‘back’ link This commit also puts this component in as many pages as possible, stripping out any hard-coded buttons and links. It replaces any usage of buttons for ‘back’, because these are links, not buttons (ie they don’t change any data).
2016-01-07 20:11:22 +00:00
{% from "components/page-footer.html" import page_footer %}
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
{% from "components/task-list.html" import task_list_wrapper, task_list_item %}
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions.
2016-01-07 12:29:56 +00:00
Include service name in page `<title>` In pages specific to a service (e.g. dashboard and sub pages) the title needs to distinguish which service it applies to. This is mainly to give context to screen reader users who could be managing multiple services. Implementing this uses template inheritance: `page_title` includes `per_page_title` includes `service_page_title` ‘GOV.UK Notify’ is inserted into every page title. Pages that set `service_page_title` get the service name inserted too.
2017-02-13 10:45:15 +00:00
{% block service_page_title %}
Update content to work in task list pattern We probably don't need to use a lead-in for a task list / table. Also moves the line about making the service live within one day to the next screen.
2018-08-29 10:19:58 +01:00
Before you request to go live
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions.
2016-01-07 12:29:56 +00:00
{% endblock %}
{% block maincolumn_content %}
Add grid column to go live checklist page To keep the line length of the text nice and comfortable.
2018-02-20 12:18:14 +00:00
<div class="grid-row">
Reword request to go live checklist page Implements Thom’s suggestions.
2018-03-12 12:29:25 +00:00
<div class="column-whole">
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
{{ page_header(
'Before you request to go live',
back_link=url_for('main.service_settings', service_id=current_service.id)
) }}
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
{% call task_list_wrapper() %}
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
{{ task_list_item(
current_service.has_estimated_usage,
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',
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
url_for('main.estimate_usage', service_id=current_service.id),
) }}
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
{{ task_list_item(
Refactor go-live readyness into service model All this info is info about the service. So it’s better to put it on the service model because: - encapsulation - later reuse
2018-09-20 09:43:28 +01:00
current_service.has_team_members,
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
2018-09-21 14:24:31 +01:00
'Add a team member who can manage settings, team and usage',
url_for('main.manage_users', service_id=current_service.id),
Check for team members on request to go live page One of the things that we want to check before a service goes live is that they have at least two team members with the manage service permission. Anyone who can make a request to go live has this permission, so that means one additional user is needed. This is what we can automatically communicate to the user. Under the hood this makes use of the logic added in https://github.com/alphagov/notifications-admin/pull/1891
2018-02-27 11:33:26 +00:00
) }}
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
{{ task_list_item(
Refactor go-live readyness into service model All this info is info about the service. So it’s better to put it on the service model because: - encapsulation - later reuse
2018-09-20 09:43:28 +01:00
current_service.has_templates,
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
2018-09-21 14:24:31 +01:00
'Add templates with examples of the content you plan to send',
url_for('main.choose_template', service_id=current_service.id),
Check for templates before going live We need users to have created some templates before they go live, so we can see what kind of messages they intend to send. We can do this automatically based on the work done in https://github.com/alphagov/notifications-admin/pull/1892
2018-02-27 12:07:50 +00:00
) }}
Fix the logic about showing extra task list items It should be: - if they have said they are going to send by a certain channel, show the extra required task(s) for that channel - if they haven’t said, infer from which templates they have
2019-03-08 14:26:39 +00:00
{% if current_service.intending_to_send_email %}
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
{{ task_list_item(
Refactor go-live readyness into service model All this info is info about the service. So it’s better to put it on the service model because: - encapsulation - later reuse
2018-09-20 09:43:28 +01:00
current_service.has_email_reply_to_address,
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
2018-09-21 14:24:31 +01:00
'Add an email reply-to address',
url_for('main.service_email_reply_to', service_id=current_service.id),
Check for reply to email address before going live We require that a user has a real reply-to email address before going live. We can partially automate this by at least telling users who haven’t done this. This only applies for users that have email templates; we shouldn’t bother users who aren’t going to send emails about this.
2018-02-27 14:25:20 +00:00
) }}
{% endif %}
Only hide channel-specific tasks if volume is 0 If you have email templates but haven’t told us what volumes you’re sending we should assume you are going to send emails. We should only stop asking you to add a reply-to address once you’ve told us for sure you’re not going to send any emails. This also applies to changing the text message sender – this should only be hidden if you don’t have text message templates or you’ve said you’re not going to be sending any text messages.
2019-03-05 10:30:40 +00:00
{% if (
Fix the logic about showing extra task list items It should be: - if they have said they are going to send by a certain channel, show the extra required task(s) for that channel - if they haven’t said, infer from which templates they have
2019-03-08 14:26:39 +00:00
current_service.intending_to_send_sms
Only hide channel-specific tasks if volume is 0 If you have email templates but haven’t told us what volumes you’re sending we should assume you are going to send emails. We should only stop asking you to add a reply-to address once you’ve told us for sure you’re not going to send any emails. This also applies to changing the text message sender – this should only be hidden if you don’t have text message templates or you’ve said you’re not going to be sending any text messages.
2019-03-05 10:30:40 +00:00
and current_service.shouldnt_use_govuk_as_sms_sender
) %}
Check text message sender before going live We often check that a service has an appropriate text message sender as a condition of them going live. We don’t mention this anywhere. The services for whom GOVUK is definitely not an appropriate sender are those in local government. As we have more of these teams starting to use Notify, we should streamline the process by making this check automated. This commit adds that check, for teams who: - have text message templates - have self-declared as NHS or local government
2018-08-23 16:11:08 +01:00
{{ task_list_item(
Refactor go-live readyness into service model All this info is info about the service. So it’s better to put it on the service model because: - encapsulation - later reuse
2018-09-20 09:43:28 +01:00
not current_service.sms_sender_is_govuk,
Make task list read better for screen readers This duplicates how the task list pattern is coded in the GOV.UK Prototype kit[1]. It adds ARIA attributes and the use of a semantically-meaningful element (`<strong>`) to give more information to screen reader users. 1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
2018-09-21 14:24:31 +01:00
'Change your text message sender name',
url_for('main.service_sms_senders', service_id=current_service.id),
Check text message sender before going live We often check that a service has an appropriate text message sender as a condition of them going live. We don’t mention this anywhere. The services for whom GOVUK is definitely not an appropriate sender are those in local government. As we have more of these teams starting to use Notify, we should streamline the process by making this check automated. This commit adds that check, for teams who: - have text message templates - have self-declared as NHS or local government
2018-08-23 16:11:08 +01:00
) }}
{% endif %}
Add line about MOU to checklist 2/3 of our incomplete requests to go live are incomplete because the Data Sharing and Financial Agreement isn’t signed. We reckon we can be pushier about this by saying it’s ‘incomplete’ where we know the agreement is signed. Where the agreement is signed we should confirm this, rather than make the line disappear. This is so it makes more sense to someone who sees it as ‘incomplete’, signs it, then comes back to the page. If we don’t know whether or not the agreement is signed we should wait until someone has got in touch with us by requesting to go live to figure it out. So that’s why we’re not showing that line at all.
2018-09-21 14:43:54 +01:00
{% if show_agreement %}
{{ task_list_item(
agreement_signed,
Make wording around agreement more straightforward We think that the next page explains the nuance around service vs organisation sufficiently well.
2018-09-26 10:16:00 +01:00
'Sign our data sharing and financial agreement',
Link request to go live to service agreement page To make it easier for users to go back and forth.
2019-05-01 15:16:15 +01:00
url_for('main.service_agreement', service_id=current_service.id),
Add line about MOU to checklist 2/3 of our incomplete requests to go live are incomplete because the Data Sharing and Financial Agreement isn’t signed. We reckon we can be pushier about this by saying it’s ‘incomplete’ where we know the agreement is signed. Where the agreement is signed we should confirm this, rather than make the line disappear. This is so it makes more sense to someone who sees it as ‘incomplete’, signs it, then comes back to the page. If we don’t know whether or not the agreement is signed we should wait until someone has got in touch with us by requesting to go live to figure it out. So that’s why we’re not showing that line at all.
2018-09-21 14:43:54 +01:00
) }}
{% endif %}
Use task list pattern for request to go live We’ve found a significant property of users (about 25%) who request to go live aren’t completing all the items on the checklist. In 1 of 6 (17%) of the usability testing sessions we did on this process we saw someone skip straight past the checklist page because of big green button syndrome. While 1 in 6 people would normally be a small number[1] in the context of a usability testing session, it’s enough to cause a big workload for our team (assuming it is the sole cause of people not completing the items on the checklist). The initial reason for using the tick cross pattern for the checklist was: - it was coherent with the rest of Notify - the task list pattern didn’t have a way of showing that something still needed doing – it put more visual emphasis on the things the user had already done There’s been some interesting discussion on the GOV.UK Design System backlog about users failing to complete items in the task list. A few people have tried different patterns for communicating that items in the task list still need ‘completing’. So this commit: - adds a task list pattern - uses the task list pattern for the request to go live checklist The task list is adapted from the one in the design system in that: - the ‘completed’ label has a black, not blue background (because Notify often uses blocks of blue to indicate something that’s clickable) - it adds an explicit ‘not complete’ label which is visually not filled in (sort of how ticked/unticket radio buttons work) 1. With the caveat that looking only at task completion, or quantifying qualitative not good practices and the intention here is to show that the numbers are close enough to say that they could be symptomatic of the same problem. Leisa Reichelt’s Mind the Product talk is good on this https://vimeo.com/284015765
2018-08-23 14:15:16 +01:00
{% endcall %}
Block incomplete requests to go live Dealing with users who request to go live but haven’t completed all the steps still represents a significant support overhead for our team. We’ve made some improvements to the percentage of incomplete requests with a better page design, but ultimately because it still shows the button people think it’s OK to press the button while some of the items on the page still say [Not completed]. We can do this now because organisations are in the database, which means we can mark the agreement signed as soon as we get it back, without having to deploy code.
2019-04-11 14:35:30 +01:00
{% if not current_user.is_gov_user %}
<p>
Only team members with a government email address can request to go live.
</p>
{% elif (not current_service.go_live_checklist_completed) or (show_agreement and not agreement_signed) %}
<p>
Update app/templates/views/service-settings/request-to-go-live.html Co-Authored-By: quis <me@quis.cc>
2019-04-11 15:43:26 +01:00
You must complete these steps before you can request to go live.
Block incomplete requests to go live Dealing with users who request to go live but haven’t completed all the steps still represents a significant support overhead for our team. We’ve made some improvements to the percentage of incomplete requests with a better page design, but ultimately because it still shows the button people think it’s OK to press the button while some of the items on the page still say [Not completed]. We can do this now because organisations are in the database, which means we can mark the agreement signed as soon as we get it back, without having to deploy code.
2019-04-11 14:35:30 +01:00
</p>
{% else %}
Don’t let non-government users request to go live Only users who work for government can accept the terms of use. This will save us from having to email these requesters back telling them they need to find someone else to submit the request.
2018-12-12 12:54:22 +00:00
<p>
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
When we receive your request we’ll get back to you within one working day.
Don’t let non-government users request to go live Only users who work for government can accept the terms of use. This will save us from having to email these requesters back telling them they need to find someone else to submit the request.
2018-12-12 12:54:22 +00:00
</p>
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
<p class="bottom-gutter">
By requesting to go live you’re agreeing to our <a href="{{ url_for('.terms') }}">terms of use</a>.
Don’t let non-government users request to go live Only users who work for government can accept the terms of use. This will save us from having to email these requesters back telling them they need to find someone else to submit the request.
2018-12-12 12:54:22 +00:00
</p>
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
{% call form_wrapper() %}
{{ page_footer('Request to go live') }}
{% endcall %}
Don’t let non-government users request to go live Only users who work for government can accept the terms of use. This will save us from having to email these requesters back telling them they need to find someone else to submit the request.
2018-12-12 12:54:22 +00:00
{% endif %}
Add grid column to go live checklist page To keep the line length of the text nice and comfortable.
2018-02-20 12:18:14 +00:00
</div>
</div>
Add pages for ‘service settings’ flow Adds the pages and wires them together, so that it’s possible to click through them. The wording is not quite English, but attempts to be an rough description of what the consequences are for each of the four actions.
2016-01-07 12:29:56 +00:00
{% endblock %}
Reference in New Issue Copy Permalink