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

36 lines
1.3 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" %}
{% from "components/checkbox.html" import checkbox_group %}
{% from "components/textbox.html" import textbox %}
{% from "components/radios.html" import radios %}
{% from "components/page-footer.html" import page_footer %}
{% 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 %}
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 %}
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
Request to go live
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 %}
{% block maincolumn_content %}
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">Request to go live</h1>
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
{% 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">
Replace channels and volumes with volumes/channel Now that we’re a more mature platform we don’t care so much about the load that one service might put on our platform. We do care about intended volumes for two reasons: - modelling the benefits that services get from using Notify - managing stocks of envelopes (while our letter volumes are small enough that they could be skewed by one new service) Changing to the ‘how many per year’ question also has the benefit of mapping directly to the data we store in the ‘beta partners’ spreadsheet.
2018-08-30 11:00:39 +01:00
{{ textbox(form.volume_email, width='1-2', hint='For example, 1,000,000') }}
{{ textbox(form.volume_sms, width='1-2', hint='For example, 500,000') }}
{{ textbox(form.volume_letter, width='1-2', hint='For example, 5,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>
Add question about research consent Since GDPR came into effect it’s less clear about whether we can contact teams for user research purposes. If we make people opt-in (or not) we know we’re safe to contact them (or not). Since we mostly care about how services are using Notify for real (ie live services) or services that are considering adopting it (ie those who have contacted us with a question) it feels like the go-live process is the most appropriate place to collect this consent.
2018-08-30 11:51:34 +01:00
{{ radios(form.research_consent, hint='You don’t have to take part and you can unsubscribe at any time') }}
<p>
When we receive your request we’ll get back to you within one working day.
</p>
Tweak spacing
2018-03-13 11:35:45 +00:00
<p class="bottom-gutter">
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
By requesting to go live you’re agreeing to our <a href="{{ url_for('.terms') }}">terms of use</a>.
</p>
{{ page_footer('Request to go live') }}
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 %}
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