app/templates/views/add-service.html

{% extends "withoutnav_template.html" %}
{% from "components/radios.html" import radios %}
{% 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 per_page_title %}
  {{ heading }}
{% endblock %}

{% block maincolumn_content %}

<div class="govuk-grid-row">
  <div class="govuk-grid-column-two-thirds">

    {{ page_header('About your service') }}

    {% call form_wrapper() %}

      {{ textbox(form.name, hint="You can change this later") }}

      {% if not default_organisation_type %}
        {{ radios(form.organisation_type) }}
      {% endif %}

      {{ page_footer('Add service') }}

    {% endcall %}

  </div>
</div>

{% endblock %}
Make spacing and position of banners consistent Banners should always be the first thing on the page. Because headers already have padding we don’t want to put padding on the container. So banners should also have top padding to distance then from the red bar. They should also sit in the 3/4 column if the page has side navigation. This commit adds a new template (`withoutnav_template.html`) which extends `admin_template.html`. All views then extend one or the other, never the `admin_template.html` directly. This means that `admin_template.html` doesn’t have to make decisions about where the flash messages are displayed. 2016-02-01 12:15:38 +00:00			`{% extends "withoutnav_template.html" %}`
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not. 2017-10-04 11:49:32 +01:00			`{% from "components/radios.html" import radios %}`
Add a WTForms-compatible textbox macro This macro: - accepts a WTForm form field as a parameter - renders a form field which follows the GOV.UK Elements patterns, both visually and in markup terms It then changes any page which uses either: - the old, non-WTForms macro or - the old, WTFforms `render_field` macro …to use this new macro and removes both of the old ones. It also adds the option to display hint text above the textbox. 2016-01-11 13:15:10 +00:00			`{% from "components/textbox.html" import textbox %}`
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 %}`
Page for adding a new service This page is exactly the same as the page for adding your first service, save the heading text. So all this commit does is: - set up two routes (`/add-service`, `/add-service/first`) for each of the two journeys and change the existing journeys to use the `/add-service/first` route - add logic to show different heading text depending on the journey - add a link to the new (`/add-service`) route in the service chooser dropdown 2016-01-18 10:47:53 +00:00			`{% from "components/page-footer.html" import page_footer %}`
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 %}`
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit. 2015-11-25 16:21:28 +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 per_page_title %}`
			`{{ heading }}`
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit. 2015-11-25 16:21:28 +00:00			`{% endblock %}`

Make spacing and position of banners consistent Banners should always be the first thing on the page. Because headers already have padding we don’t want to put padding on the container. So banners should also have top padding to distance then from the red bar. They should also sit in the 3/4 column if the page has side navigation. This commit adds a new template (`withoutnav_template.html`) which extends `admin_template.html`. All views then extend one or the other, never the `admin_template.html` directly. This means that `admin_template.html` doesn’t have to make decisions about where the flash messages are displayed. 2016-02-01 12:15:38 +00:00			`{% block maincolumn_content %}`
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit. 2015-11-25 16:21:28 +00:00
Fix class name Co-Authored-By: Chris Hill-Scott <me@quis.cc> 2020-03-06 12:50:12 +00:00			`<div class="govuk-grid-row">`
Replace `column-two-thirds` with `govuk-grid-column-two-thirds` 2020-02-19 12:36:02 +00:00			`<div class="govuk-grid-column-two-thirds">`
Page for adding a new service This page is exactly the same as the page for adding your first service, save the heading text. So all this commit does is: - set up two routes (`/add-service`, `/add-service/first`) for each of the two journeys and change the existing journeys to use the `/add-service/first` route - add logic to show different heading text depending on the journey - add a link to the new (`/add-service`) route in the service chooser dropdown 2016-01-18 10:47:53 +00:00
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('About your service') }}`
Page for adding a new service This page is exactly the same as the page for adding your first service, save the heading text. So all this commit does is: - set up two routes (`/add-service`, `/add-service/first`) for each of the two journeys and change the existing journeys to use the `/add-service/first` route - add logic to show different heading text depending on the journey - add a link to the new (`/add-service`) route in the service chooser dropdown 2016-01-18 10:47:53 +00:00
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() %}`
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app 2016-02-18 14:54:59 +00:00
Updates to ‘send SMS’ page Based on discussion with Pete. Make the blue banner an ‘important’ banner (copied from Register to Vote, used because it’s not as boxy and fits on the page better). Remove the back button because you haven’t changed any data yet. If you need to go back you can just press back or start again. Make the filename stand out more. Remove the ‘download example’ link. Will need to revist the best way of doing this. Make text messages consistently 2/3rd width. 2016-02-04 12:20:24 +00:00			`{{ textbox(form.name, hint="You can change this later") }}`
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app 2016-02-18 14:54:59 +00:00
Only show nhs radios if user has nhs domain email Also split local NHS into two groups following designer advice on readability. 2019-07-16 15:37:27 +01:00			`{% if not default_organisation_type %}`
Don’t ask for organisation type when we know it Every time someone adds a new service we ask them what kind of organisation they work for. We can look this up based on the user’s email address now. So we should only ask the question if: - we don’t know about the organisation - or we haven’t set what type of organisation it is (this shouldn’t be possible on productions because we’ve populated the column for all existing organisations and it’s impossible to add a new one without setting it 2019-04-18 12:44:18 +01:00			`{{ radios(form.organisation_type) }}`
			`{% endif %}`
Collect organisation type So that we can default services to their appropriate text allowance, we need to find out what sector they're in. So let's start collecting that from teams as they create new services. I think Central/Local/NHS are the right options, but these can be easily changed if not. 2017-10-04 11:49:32 +01:00
Reword the add service page Without the preview service name we probably have to go back to communicating a bit more on the add service page. This commit brings back the two bullet points about where the service name will appear, and tries to tie it into the nice words that Matt Sheret wrote for us. 2016-02-26 10:46:49 +00:00			`{{ page_footer('Add service') }}`
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app 2016-02-18 14:54:59 +00:00
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 %}`
Page for adding a new service This page is exactly the same as the page for adding your first service, save the heading text. So all this commit does is: - set up two routes (`/add-service`, `/add-service/first`) for each of the two journeys and change the existing journeys to use the `/add-service/first` route - add logic to show different heading text depending on the journey - add a link to the new (`/add-service`) route in the service chooser dropdown 2016-01-18 10:47:53 +00:00
			`</div>`
Create base forms for registration and sign in Created routes and forms for registration, sign in, and registration from an invite. Also tidied up assets folder, removed copy of fronted toolkit. 2015-11-25 16:21:28 +00:00			`</div>`

Updated the title tag to be useful [ci skip] 2015-12-01 09:50:20 +00:00			`{% endblock %}`