We’ve had some feedback that the map key icons look a bit like
checkboxes, and that this might have confused a user during the
research.
So we need a way of making them look different to checkboxes. We don’t
want to change the border thickness because it matches what’s on the
map. A different approach is changing the shape.
Shapes that might still be confusing:
- circles (look like radio buttons)
- triangles (look like a warning)
So this commit changes the shape to a diamond, which is easy to acheive
by rotating the square 45 degrees.
We’ve had some feedback that relying only on luminosity and position to
differentiate between the ‘will get alert’ and ‘likely to get alert’
areas on the map might not be enough.
We don’t want to introduce another colour because:
- it will make the map look very busy
- not many other colours contrast with the map tiles as well as blue
- relying on colour only to communicate information is also bad for
accessibility
Instead we can make one of the lines a different style. I’ve gone for
dashed on the ‘likely’ line because it looks nice, and gives some
suggestion of a porous boundary.
Implementing this means using CSS border image, because a `dashed`
border (which we still have as a fallback) doesn’t render with
consistent dash sizes from browser to browser. We need consistency to
match the dashes that the map will be drawing (which use SVG not CSS
so don’t have the same problem).
We’ve had some feedback from user research that difference between
‘will get alert’ and ‘likely to get alert’ is not clear, and it’s hard
to tell if the latter is inclusive of the former. This leads people to
question the validity of these numbers, which is important, because an
the estimate should give you some idea of the impact of what you’re
about to do.
This commit reformats the number as a range, for example 1,000 to 2,000
phones.
If the range is small, eg 40,000,000 to 40,800,000 then this suggests
a false level of accuracy. So instead we just give one number and say
it’s an estimate, eg ‘40,000,000 phones estimated’
It was missing the base class so didn’t get all the styling (like the
spacing and uppercase text).
Already fixed this for step 6, but less haste, more speed.
We want it to be very clear whether you’re in live or training mode
because:
- you may be switching back and forth between them
- doing something in live mode when you think you’re in training mode
would have… consequences
By adding a label next to the service name you’ll will have some
indication, on every page, which mode you are in.
Style of the label is based on the ‘Tag’ component from the Design
System:
https://design-system.service.gov.uk/components/tag/#showing-multiple-statuses
It clashes with the new `$govuk-focus-colour` now. This commit changes
it to half way between `govuk-colour("dark-grey")` (`#505a5f`) and
`govuk-colour("mid-grey")` (`#b1b4b6`) from the Design System. Dark was
too dark and mid was too light.
It also adds a line of JS to let us easily switch the header to blue by
clicking on it, which is useful for taking screenshots etc.
There are a few places where we missed updating to the new focus styles
because they were using the `$yellow` SASS variable and not the
`$focus-colour` variable.
This commit updates them to the new colour, and where needed adds the
black lower border to match.
we want to keep track of all broadcast services across govt easily. As
such, when broadcasting is enabled for a service, we've decided we're
going to add the service to a special broadcasting organisation.
This organisation is defined in the config file. It's hard coded for
production, if you want to test locally, you should set
BROADCAST_ORGANISATION_ID in your local environment.
If you’re adding another area to your broadcast it’s likely to be close
to one of the areas you’ve already added.
But we make you start by choosing a library, then you have to find the
local authority again from the long list. This is clunky, and it
interrupts the task the user is trying to complete.
We thought about redirecting you somewhere deep into the hierarchy,
perhaps by sending you to either:
- the parent of the last area you’d chosen
- the common ancestor of all the areas you’d chosen
This approach would however mean you’d need a way to navigate back up
the hierarchy if we’d dropped you in the wrong place. And we don’t have
a pattern for that at the moment.
So instead this commit adds some ‘shortcuts’ to the chose library page,
giving you a choice of all the parents of the areas you’ve currently
selected. In most cases this will be one (unitary authority) or two
(county and district) choices, but it will scale to adding areas from
multiple different authorities.
It does mean an extra click compared to the redirect approach, but this
is still fewer, easier clicks compared to now.
This meant a couple of under-the-hood changes:
- making `BroadcastArea`s hashable so it’s possible to do
`set([BroadcastArea(…), BroadcastArea(…), BroadcastArea(…)])`
- making `BroadcastArea`s aware of which library they live in, so we can
link to the correct _Choose area_ page
We want to change cache keys for templates and broadcasts to include
their service ID. So cache keys should change from
`template-{template_id}-versions` to
`service-{service_id}-template-{template_id}-versions`.
The first step of this which needs to be deployed as a change first is
to delete both keys when updating service templates (even if they key is
not yet set). This means that when we release code in the next PR to
start setting the new key, we won't run into a case where either the old
or the new key can remain set with stale data.
