Because we’re be grouping jobs under their parent contact lists it’s
good to have some information ‘scent’ to help people find their jobs,
ie by clicking into a contact list. It also lets you see which list have
been used more than others, maybe because the update hasn’t been sent
to that group of people yet.
The hint text under uploads always says when they were used. For contact
lists this is a bit more complicated, since they can:
- never have been used
- been used multiple times
This commit makes use of the new fields being returned by the API to say
determine when these messages are relevant. They also let us
differentiate between a contact list that’s never been used, and one
that has been used, but not recently enough to show any jobs against it.
Pill pages are:
- /notifications
- /template-usage
- /monthly
- /organisations/<organisation_id>
- /templates
Includes changes to:
- the folder-path component
- the page-header component
...all their h1s have the same id.
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
By default our AJAX calls were 2 seconds. Then they were 5 seconds
because someone reckoned 2 seconds was putting too much load on the
system. Then we made them 10 seconds while we were having an incident.
Then we made them 20 seconds for the heaviest pages, but back to 5
seconds or 2 seconds for the rest of the pages.
This is not a good situation because:
- it slows all services down equally, no matter how much traffic they
have, or which features they have switched on
- it slows everything down by the same amount, no matter how much load
the platform is under
- the values are set based on our worst performance, until we manually
remember to switch them back
- we spend time during incidents deploying changes to slow down the
dashboard refresh time because it’s a nothing-to-lose change that
might relieve some symptoms, when we could be spending time digging
into the underlying cause
This pull request makes the Javascript smarter about how long it waits
until it makes another AJAX call. It bases the delay on how long the
server takes to respond (as a proxy for how much load the server is
under).
It’s based on the square root of the response time, so is more sensitive
to slow downs early on, and less sensitive to slow downs later on. This
helps us give a more pronounced difference in delay between an AJAX call
that is fast (for example the page for a single notification) and one
that is slow (for example a dashboard for a service with lots of
traffic).
*Some examples of what this would mean for various pages*
Page | Response time | Wait until next AJAX call
---|---|---
Check a reply to address | 130ms | 1,850ms
Brand new service dashboard | 229ms | 2,783ms
HM Passport Office dashboard | 634ms | 5,294ms
NHS Coronavirus Service dashboard | 779ms | 5,977ms
_Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms
GOV.UK email dashboard | `HTTP 504` | 😬
Dashboard is the most intensive page we AJAX, and also the highest
traffic one. We’ve already slowed it from 2 to 5 seconds, this slows it
further to 20 seconds to reduce the load.
This leaves other pages (for example looking at a single job) at the
platform-level default of 5 seconds, because we think they cause less
load and the real-timelyness isn’t critical to people’s business
processes.
For looking at a single notification we know from research that someone
sending these one-at-a-time often waits to see if they’re delivered,
so let’s bring this back down to the previous value of 2 seconds.
24px with 19px is what we use on the uploads page. On notifications page
we use 19px with 16px.
There’s some loose idea that the bigger size is for items that contain
other items.
This also increases the line height for recipients of PDF letters to
make things line up.
Uploads page is where all the stuff you’ve uploaded lives. Now you can
upload contact lists they should live here too.
They always come first because they’re the most-removed from stuff
you’ve sent.
We’ve done this already for services with the upload letters permission.
And all services can upload letters now.
But we’re still returning it in the JSON response we use to AJAX-ify the
page.
Since the jobs response can query stats for up to 50 jobs at a time this
puts some load on the API/database. Hopefully this might drop that load
a bit.
The default is 2 seconds and this will mean that we are halving traffic
for these ajax calls which can only be good for trying to limit queries
on the database.
I think the user impact on this will likely not be noticable.
Debatable whether we should up them all even further to 10 seconds but
this is definitely a quick although maybe small win.
Now that scheduled jobs are mixed in with regular jobs it looks weird
for the sort order to be different. This makes the sort order
consistently go from furthest in the future to furthest in the past.
The old sort order made sense when scheduled jobs were displayed
separately on the dashboard.
We didn’t have a test that checked for the first two lines of the
address being displayed when rendering one-off letters on the uploads
page.
I double checked in the database and we store addresses in the `to`
field with newlines, not commas.
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Scheduled jobs push everything else on the dashboard down, which makes
them very prominent. This is exacerbated by people scheduling more jobs
simultaneously than we expected when we originally designed the feature.
We also want to remove all jobs from the dashboard, in favour of putting
them on the uploads page.
So this commit replaces them with one of our new dashboard banners (used
for received text messages in returned letters) which summarises:
- how many scheduled jobs you have
- when the first one is going out (i.e. how long you have to stop it, if
you need to)
This is the same thing we do for caseworking users who don’t have the
dashboard. Since we’re going to summarise scheduled jobs on the
dashboard instead of listing them they need to be listed here instead
(which is where we’ll link to from the dashboard).
Design of this will probably evolve as we work out how to style single
letter uploads and letter jobs, but that’s OK for now because no-one
has the uploads page at the moment.
Currently you have no way of getting to the returned letter page. This
commit adds a link to it from the dashboard, following the pattern of
the new received text messages banner.
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
This is semantically more accurate because it’s describing the whole
table, not just the first column.
Adjusting the font-size to make it sit within the ‘In the last 7 days’
section. Adjusting the spacing because now that we have more borders we
don’t need quite so much whitespace to separate different bits of the
page.
This commit adds a new kind of banner to the dashboard for summarising
things you might need to action.
This way we’ll be able to have multiple instances of this banner on the
same page without it looking too intense.
I never really liked the big blue banner for inbound text messages
because it became the most prominent thing on the page. It was an
interim solution that let us ship the feature until we had something
better.
This makes the template statistics section of the dashboard look less
like its own weird thing and more like:
- the templates page
- the upcoming changes to the styling of the received text messages
banner on the dashboard
This follows the pattern of what we’ve done with services, users and
events.
It gives us a way of neatly instantiating a model for each item in the
list we get back from the API and reduces the complexity of the view
layer code.
Now is a good time to do this because we’re going to be making a bunch
of changes to the jobs pages, and those changes will be easier to code
and understand with a sensible model behind them.
