This should:
- make the page load faster because it has to render less HTML for each
service
- make the page easier to scan for services that are sending lots of
text messages or letters
We used to scan this page to look for services with high failure rates,
and the design of the page was gear towards this. Now we have alerting
for high failure rates, so the page can focus on volumes instead.
This commit also puts the service name above the statistics, so that
long service names don’t break the layout of the page.
This commit changes all the places where a user would see the term
‘whitelist’ in the content of page to say guestlist instead.
We’re removing the term ‘whitelist’ for two reasons. The first reason
is that we agree with the National Cyber Security Centre say:
> It's fairly common to say whitelisting and blacklisting to describe
> desirable and undesirable things in cyber security. For instance, when
> talking about which applications you will allow or deny on your
> corporate network; or deciding which bad passwords you want your users
> not to be able to use.
> However, there's an issue with the terminology. It only makes sense if
> you equate white with 'good, permitted, safe' and black with 'bad,
> dangerous, forbidden'. There are some obvious problems with this. So
> in the name of helping to stamp out racism in cyber security, we will
> avoid this casually pejorative wording on our website in the future.
> No, it's not the biggest issue in the world - but to borrow a slogan
> from elsewhere: every little helps.
– https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white
The second reason is that we’ve observed some users think that they have
to put recipients in the whitelist even when they’re already with in the
team. We think that the term ‘whitelist’ might be reinforcing this
mental model because of how ‘whitelists’ might work in other
applications.
We considered the following alternatives or concepts:
- Development
- Recipients
- Sandbox
- Extended team
- Smoke test recipients
- Allowed
- Nominated
- Bonus
- Additional
- Safe
- Team list
- Trusted contacts
- Designated people
- Guest list
- Team key list
We also considered not giving it a name, and explaining it as a nuance
of how the team key works. After mocking this up it felt more disjoined.
We think it’s still useful for the thing to have a name so that it’s
easy to refer to between the docs and the UI.
We like the term ‘guest list’ because:
- of how it sits with team members – members and guests in the abstract
- a guest list is a concept that a lot of people will be familiar with
– a list of people who can access a thing
- ‘guest’ is very different to ‘recipient’ – we want to mitigate any
confusion between this and the (emergency) contact lists
All paragraphs should have class="govuk-body", or be otherwise
custom-styled. This commit adds some extra checks to our test fixture
that looks for paragraphs that don’t have any styling. Our test coverage
is pretty good, so this should check almost all pages, and prevent
regressions.
I’ve done this in such a way that it can be extended for other elements
(e.g. links) in the future.
Google’s documentation says:
> robots.txt is not a mechanism for keeping a web page out of Google. To
> keep a web page out of Google, you should use noindex directives
A noindex directive means adding the following meta tag to pages that
shouldn’t be indexed:
```html
<meta name="robots" content="noindex" />
```
It’s also possible to set the directive as a HTTP header, but this seems
trickier to achieve on a per-view basis in Flask.
I’ve implemented this as a decorator so it can quickly be added to any
other pages that we decide shouldn’t appear in search results.
International letters don’t have a choice of postage. Under the hood
they are either `europe` or `rest-of-world`.
So, for letters that we detect are international, this commit:
- removes the radios buttons that give users the choice of postage
- passes through either `europe` or `rest-of-world` to the API,
depending on what address we find in the letter
This will cause the API to 500 until it can accept `europe` or
`rest-of-world` as postage types, but this is probably OK because it’s
only our services that have international letters switched on at the
moment.
The endpoint works fine with it in the URL now instead, so we need stop
posting it. We can’t stop expecting it yet, because some old instances
will still be posting to the endpoint without the ID in the url.
By deep linking to the support form we skip the question that asks if
someone is a member of the public.
This seems like a helpful thing when we’re directing people to where
they can ask for document download to be switched on. But what I think
is happening (backed up from one example I can see in Kibana):
1. Someone searches for something like ‘email GOV.UK’
2. They land on https://www.notifications.service.gov.uk/features/email
3. They scan the page and think, hmm not sure what this is, I’m not
seeing what I’m looking for here…
4. …but aha, there’s a link that says ‘contact us’
5. They click it and land on
https://www.notifications.service.gov.uk/support/ask-question-give-feedback
which has a nice big box to type in
This commit removes these deep links from non-logged-in pages, so that
everyone has to go through the ‘are you a member of the public’ question
before they get to the big typey box.
Includes:
1. changes to make NestedFieldMixin work
with new fields and CSS for nested checkboxes
2. adds custom version of GOVUK checkboxes
component to allow us to:
- add classes to elements currently inaccessible
- wrap the checkboxes in a list
- add child checkboxes to each checkbox (making
tree structures possible through recursion
Change 2. should be pushed upstream to the GOVUK
Design System as a proposal for changes to the
GOVUK Checkboxes component.
If you’ve come to look at a notification via the uploaded letters page
then the ‘< back’ link should take you back there, not to the usual
activity page.
Some teams have started uploading quite a lot of letters (in the
hundreds per week). They’re also uploading CSVs of emails. This means
the uploads page ends up quite jumbled.
This is because:
- there’s just a lot of items to scan through
- conceptually it’s a bit odd to have batches of things displayed
alongside individual things on the same page
So instead we’re going to start grouping together uploaded letters. This
will be by the date on which we ‘start’ printing them, or in other
words the time at which they can no longer be cancelled.
This feels like a natural grouping, and it matches what we know about
people’s mental models of ‘batches’ and ‘runs’ when talking about
printing.
This grouping will be done in the API, so all this commit need to do is:
- be ready to display this new type of pseudo-job
- link to the page that displays all the uploaded letters for a given
print day
Because we won’t be showing uploaded letters individually on the uploads
page any more we need a way of listing them. This should be by printing
day, to match how we’re grouping them on the uploads page.
This code reuses the notifications.html template, but flips the
precedence of the filename and recipient because I reckon when you’re
looking at uploads you’re thinking filename-first.
