Users come to this page from various places, including the new 'Sign
the…' link on the request to go live page.
Of these users:
- some won't have signed it
- some will have signed it
- some will see that it's complete and wonder why, as they haven’t
actually done anything
So it’s more appropriate for the title of this page to be descriptive,
rather than an action.
2/3 of our incomplete requests to go live are incomplete because the
Data Sharing and Financial Agreement isn’t signed.
We reckon we can be pushier about this by saying it’s ‘incomplete’ where
we know the agreement is signed.
Where the agreement is signed we should confirm this, rather than make
the line disappear. This is so it makes more sense to someone who sees
it as ‘incomplete’, signs it, then comes back to the page.
If we don’t know whether or not the agreement is signed we should wait
until someone has got in touch with us by requesting to go live to
figure it out. So that’s why we’re not showing that line at all.
This duplicates how the task list pattern is coded in the GOV.UK
Prototype kit[1]. It adds ARIA attributes and the use of a
semantically-meaningful element (`<strong>`) to give more information to
screen reader users.
1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
We don't show the sender addresses and letter branding on the settings page
if a service doesn't have letters enabled, so we should also hide the
postage for services that can't send letters.
(Postage can only be seen by Platform Admin users at the moment, but this will
change later).
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
Added a new row to the settings table, 'Post class', which shows the
default letter class of a service and is only visible to Platform Admin.
Also added a new page to enable Platform Admin users to change the
default letter class for a service - this only has two options at the
moment, 1st class only and 2nd class only.
A platform admin form accepts a list of references (one per line)
received from DVLA and sends them to the API to update notification
statuses.
References we get from DVLA start with `NOTIFY00\d`, which isn't
part of the reference we store in the database, so we remove them
before sending the data to the API.
The new `returned-letter` status should be treated as `delivered`
for now until we decide a way to display returned letters to users.
Because ‘2 months ago’ is more human-sounding than ‘70 days ago’.
Using this pattern (borrowed from the API integration page) will also
use Javascript to keep the time updated, so ‘just now’ will turn into
‘1 minute ago’ without having to reload the page.
It’s useful to be able to see what the email or text message looks like,
especially if you’ve sent it with a test API key (so it isn’t in your
inbox or on your phone). We already have the page for this, so we just
need to link to it.
So that:
- we can see when a brand should be getting used as a default but isn’t
- we’re careful updating brands which will get auto-applied to new
services
Document download is in private beta, which means most teams using
Notify can’t see or use it.
We shouldn’t confuse people by showing them this guidance, especially
while it’s API-only.
We sometimes have to do this over support tickets as part of the go-live
process; now we’re directing people to add a sender (as part of the task
list) we can explain what it is in context.
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.
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.
This is just the pricing page, we'll sort the pricing table etc separately...
W're removing non-crown pricing as we won't be charged differently any more. But we will retain the concept of non-crown as we may change differently ourselves in the future.
