app/templates/views/add-service.html

{% extends "withoutnav_template.html" %}
{% from "components/textbox.html" import textbox %}
{% from "components/page-footer.html" import page_footer %}

{% block page_title %}
  {{heading}} – GOV.UK Notify
{% endblock %}

{% block maincolumn_content %}

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

    <h1 class="heading-large">
      When people receive notifications, who should they be from?
    </h1>

    <form autocomplete="off" method="post">

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

      {{ page_footer('Add service') }}

    </form>

  </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" %}
-												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 %}
-												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 %}
-												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
 								{% block page_title %}
-												Make page titles consistent

This commit modifies the HTML `<title>` tags for all the pages. It makes two
main changes:
- make the title tag match the `<h1>` of the page, for better or worse
- put the service name after the page title, seperated by an en dash, as per
  GOV.UK

											
										
										
											2016-02-08 09:23:51 +00:00
+								  {{heading}} – GOV.UK Notify
-												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
 								<div class="grid-row">
-												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 class="column-two-thirds">
-												Make headings `.heading-large` instead of `.heading-xlarge`

											
										
										
											2016-02-02 14:05:45 +00:00
+								    <h1 class="heading-large">
-												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
+								      When people receive notifications, who should they be from?
-												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
+								    </h1>
 								    <form autocomplete="off" method="post">
-												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
-												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
-												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
+								    </form>
 								  </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 %}