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

59 lines
2.3 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" %}
Add letters to the request to go live page It’s not either text messages, or emails, or both now – it’s any combination of the three channels. This commit adds ‘letters’ as an option on the request to go live page by changing the radio buttons to a group of checkboxes, so the user can choose as many or as few as they want. This commit also does a bunch of housekeeping stuff around the tests for this page, because they haven’t been touched in quite some time.
2017-09-27 10:46:52 +01:00
{% from "components/checkbox.html" import checkbox_group %}
Put a form on the request to go live page This commit: - moves things around a bit on the request to go live page - sticks a textbox in there So when someone click the big green button, we will get a support ticket that looks something like: ``` From Test User <test@user.gov.uk> on behalf of Test Service (6ce466d0-fd6a-11e5-82f5-e0accb9d11a6) --- We’ll send about 1000 text messages in the first month, and then 10,000 text messages per month after that. Usage of our service is about 50% higher in March, at the end of the tax year. ```
2016-04-26 13:31:57 +01:00
{% from "components/textbox.html" import textbox %}
Use radio buttons not textboxes for multi-choice No need to make people type when they can click, and gives us consistent data.
2016-10-31 15:05:22 +00:00
{% from "components/radios.html" import radios %}
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 %}
Fix tests and other bits
2016-10-24 15:35:51 +01:00
{% from "components/banner.html" import banner_wrapper %}
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">
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
<h1 class="heading-large">Before you request to go live</h1>
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() %}
{{ 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
) }}
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
{% if current_service.has_email_templates %}
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 %}
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
{% if current_service.has_sms_templates 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',
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
url_for('main.agreement'),
) }}
{% 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 %}
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
<p>
Reword request to go live checklist page Implements Thom’s suggestions.
2018-03-12 12:29:25 +00:00
You also need to accept our <a href="{{ url_for('.terms') }}">terms of use</a>.
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
</p>
<p>
Reword request to go live checklist page Implements Thom’s suggestions.
2018-03-12 12:29:25 +00:00
<a href="{{ url_for('main.submit_request_to_go_live', service_id=current_service.id) }}" class="button">Continue</a>
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
</p>
</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