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.
We don't want large numbers in Production to start overlapping other columns
in the tables when they have less space available, and putting these messages
at the top of the page under the h1 means that we don't need an extra column
on the page yet.
This link looked odd floating above the left column, and although we may want
to have admin navigation on the left we aren't sure what that would include
yet, so move this link to the header alongside the Platform admin link.
When we make the numbers on this page more filterable the date range will be
one of the options to change, so it makes sense to move it to the side now
instead of leaving it above the big numbers.
This page currently includes all notifications for all services, including
those sent using a test key. Stats on all other pages exclude test key usage,
though, which can lead to confusion for admins comparing numbers between
pages. Adding the option to toggle between including and excluding test key
usage on the platform admin page gives context for this difference, and allows
admins to see live usage of the platform as well as load associated with test
key usage.
Posit that examples of where you can put different parts of the address
is more helpful than ‘example, example, example’. Also shows that you
don’t have to fill all of the address columns.
Spot the Easter egg 🎅
Implements https://github.com/alphagov/notifications-utils/pull/81
Handles addresses as multiple columns:
- in ‘Send yourself a test’
- in example CSV files
- in validating that a CSV file has recipients (eg at least an ‘address
line 1’ and ‘postcode’ column)
- when showing the contents of a CSV file
As few UI changes as possible, once we have the thing working end-to-end
we can think about how the UI might need to work differently.
Let users create/edit/delete letter templates.
Let them upload a CSV file or send a test against a letter template.
Big assumption at the moment is that addresses only have one line, and
therefore one column in the CSV file.
