The url was not being properly formed, missing the tempalte_id, meaning the back button on the page did not work.
This fixes that, includes a check of the url for the back button.
Problem: it wasn’t saying ‘phone number’ or ‘email address’
Why: we renamed `Recipients.recipient_column_header` to
`Recipients.recipient_column_headers`, and made it return a list, not
a string.
The fix: take the first item of the list, and use that to decide whether
it’s phone numbers or email addresses that you’re not allowed to send
to.
N.B. This won’t work for letters, but we don’t know how trial mode is
going to work for letters anyway.
This copies what the other GaaP components will be doing for their
product pages.
The SASS and HTML is taken from here:
f05ca1fb71/source/stylesheets/modules/_breadcrumbs.scss
Only changes I’ve made are:
- making the file paths work with our build pipeline
Changes to our code to accomodate this are:
- putting the padding on the product page `<h1>` not its container
- moving the hero image accordingly so that it lines up
- making the `<main>` element on the product page into an anchor so that
the breadcrumb can link to it – screenreader will then announce the
link as “GOV.UK Notify, same page”
We grey-out the non-current step in the tour so the user knows whether
they’re at step 1, 2, or 3.
This is done using CSS opacity.
IE8 doesn’t support the standard CSS opacity syntax. But it does support
the weird, old, Microsoft-specific `filter:` syntax. So this commit:
- makes the greying out a class rather than an inline style, to reduce
duplication
- adds the filter syntax so the greying out works in IE8
The layout of the totals on the dashboard was getting horizontally
squashed on older versions of IE.
This was something to do with the `grid-row` CSS class no longer being
applied when AJAX updated the page. Grid columns don’t work properly
unless they’re contained in a grid row.
This commit wraps the `div` with `grid-row` in another `div`. Not
totally sure why this works, but it’s something to do with how the
DiffDOM algorithm is working. Seems like the simpler the diff it has to
compute, the better chance it has of not messing things up.
There is a check that the template can not be created as priority if the user is not a platform admin.
There is a check that the template can not change the `priority` unless they are a platform admin.
One of the user needs that we identified is not wanting to be the first
to use it. It feels like a much less risky choice if there are already
other people in government using it.
The easiest way to communicate this is with counts of how many services.
The count of departments is good because it shows breadth, where the
count of services shows depth.
Hard coded for now because we have no automatic way of splitting our
test services from real live services.
‘How much does it cost’ is one of the user needs that we identifed for
the product page.
Cost is not the primary reason someone would use Notify (they’re more
likely to cite ease, or that it’s ‘official’). However if you _don’t_
mention cost then it looks like we’re hiding something or that there’s
a catch. So putting it on the page allays fears that people might have,
rather than pushing them towards using it.
Visually I’ve dropped the size of the `<h2>`s on this page so that
there’s enough difference between them and the big numbers. The idea of
the big numbers being big is to catch people’s attention as they scroll
down the page, by breaking up the rythmn.
This addresses part of the ‘is Notify dependable’ group of needs.
The ones it specifically and partially addresses are:
- is it reliable
- how is it supported
There’s more to come in this section, we’re doing this bit now because
it’s a nice conclusion to the page.
Also reword some of the `<p>`s so that they flow better from the
headings.
This was a bit me, and a bit sitting down and hammering this stuff out
with Stephen and Sheryll.
This is the first step towards a fully-fledged ‘product’ page.
The needs for the top, blue section of the page are:
- what is Notify?
- can I use it?
- can I test it out?
- how do I create a log in
The needs for the next section of this page (which is the only one added
by this commit) are:
- how will Notify help me work?
- will it work with my service?
This commit shows 4 features of Notify on the home page which address
those needs. They are illustrated because:
1. We want to catch people’s attention – users are reluctant to scroll
on this page because they just want to click the ‘create account
button’. But we hypothesize that they will get on better
with Notify if they look at some of this stuff first.
2. The concepts that they’re talking about are hard to explain with just
words because they’re quite abstract. The illustrations help us be
more specific.
3. Feedback we got from user research was that the product page didn’t
give users any sense of what it was like to actually use Notify.
This copies the style that Tim and Stephen have been developing for all
product pages.
It also pulls out the CSS for this into its own file, so that it could
potentially be reused.
This is part of the new header style that Tim, Stephen et al have been
working on.
This means that we lose the feedback link, so I’m trying out having it
in the top right.
