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’
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
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
previously the back link went to choosing a library.
Now, if you view a district from a county, go back to the county page.
Otherwise, go back to the top level of the library.
For a training broadcast the user doesn’t get that immediate feedback
that something has happened, like they would with a real alert, or even
sending themselves a text message.
This commit adds another tour-style page which will interrupt their
journey and hopefully reinforce the message we’ve given them earlier in
the tour.
We’re adding this because we’ve found in research that users don’t have
a good grasp of the consequences and severity of emergency alerts,
versus regular text messages.
We need to give people a better feel for the consequences of
broadcasting an alert. We’ve seen in research that some users will
assume it is subscription based, or opt-in, rather than going to every
phone in the area.
I reckon that the most effective way to communicate this is to put some
numbers next to the areas, to give people an idea of how many people
will get alerted.
We can estimate how many phones are in an area by:
- taking the population of all electoral wards in that area
- multiplying it by the percentage of people who own an internet
connected phone[1]
The Office for National Statistics publish both these datasets.
The number of people who own an intenet connected phone varies a lot by
age. Since the population data for each ward is broken down by age we
can factor this in. Simplified, the calculation looks like this:
- take the _Abbey_ ward of _Barking and Dagenham_
- in this ward there are 26 people aged 80
- 40% of people over 65 have an internet-connected phone
- therefore 10 of these 80-year-olds would be likely to receive a
broadcast
- (repeat for all other ages)
These numbers won’t be exact, but should be enough to give people a feel
for the severity of what they’re about to do. We can see if they acheive
this aim in user research.
1. This is a proxy for the number of people who are likely to have a 4G
capable phone, because only 4G capable phones will be receiving
broadcasts to begin with
What was previously ward -> local authority is now a ward -> local
authority -> county. County only covers rural counties and not
metropolitan boroughs and other unitary authorities. Previously, there
was a page full of local authorities (unitary authorities and
districts), and each one of those would have a list of electoral wards.
However, now there are counties that contain a list of districts - so
this needs a new page - a checkbox for "select the county" and then a
list of links to district pages.
If you want to select multiple districts, you'll need to go into each
one of those sub-sections in turn and click select all.
Needed to tweak the query to retrieve the list of areas in a list for a
library. Previously, it just returned anything at top level (ie: didn't
have a parent). However, rural districts now have parents (the rural
counties themselves). So the query now returns "everything that isn't a
leaf node", or in more specific terms, everything that has at least
other row referring to it as a parent. So no electoral wards, since
they dont have any children, but yes to districts and counties.
Since the key relies on visual association between the shapes on the
maps and the styling of the key, it won’t work for non-visual users.
An alternative way of giving them the same information is by providing
the size of the area numerically.
When creating broadcast message, or updating it.
We want to send simple polygons to API so we can
later relay them to the broadcast provider.
Test that update broadcast message sends polygons correctly
This commit refines which information we show on each page.
Specifically we’re
- adding some wording (‘at exactly the same time’) to try to communicate
the immediacy
- giving the ‘loud noises’ message it’s own screen to really draw
attention to it
- moving the ‘no phone numbers bit’ later in the journey, and
experimenting with explaining why that is, to make it clearer how it’s
different to a text message
Because the ‘All of’ choice appears above the search field, it shouldn’t
be filtered by the search field.
We can fix this by wrapping the sub-areas in a `<div>` and make the
selector more specific.
We’ve shown the broadcast tour to a few users now. We’ve learned what
concepts about broadcasting are and aren’t getting through.
So what we’re emphasising here is:
- the thing that appears on the phone (the ‘emergency alert’) not the
technology (a ‘broadcast’)
- how it’s different to other channels of messaging, eg text
We’ve generally spent a lot more time on the content and illustrations
this time around, so overall it’s should be clearer and shorter.
This also expands the communication of training mode into the header,
so it’s visible on every page (we can add another one for ‘live’
services later on).
We want to let users learn the system by trying it out. At the moment
they can’t explore it fully by themselves because they’re blocked at
the point of approving the broadcast, unless they involve in another
member of their team. Having to involve another person is friction that
will discourage people from exploring.
So this adds a button that lets people approve their own broadcasts in
trial mode, with some rough-and-ready content that explains training
mode and how it would be different to trial mode.
Messages awaiting approval don’t have an end time – it’s set
automatically once the message is approved.
We need to revisit the content on this page, but this is just a fix so
that the page doesn’t `500`.
Since we added the end time picker:
- we have discovered that broadcasts can’t be longer than 24h
- we have observed that most users confuse picking the end time for
scheduling the message, or don’t understand exactly what it means for
the broadcast to ‘end’
- we’ve developed the concept of ‘training mode’, which you should be
going through before sending a real broadcast
We also think that, for most scenarios, you won’t necessarily know when
a broadcast should end at the time of starting it because the cause of
the danger is not within your control. So giving you control of the
end time before the broadcast has even been approved is a confusing
distraction.
Having to pick a time at all also makes the whole process feel more
planned and less immediate. Whereas in reality all the phones in the
area will be getting the message in seconds. It’s only people coming
into the area later to whom the ‘ongoing’ aspect of the broadcast
applies.
The best place to explain what’s happening with the phones is at the
approval stage and once you’ve sent your first (training mode)
broadcast. It’s easier to explain what’s happened if it’s in direct
response to something you’ve just done.
Later on we should add some kind of email reminder after 12 hours to
make sure you still want the broadcast live, again after 18 hours, etc.
We could let you schedule an end time once the broadcast is live, but
don’t think there’s a strong need. Knowing enough that you want to
cancel is one thing, but knowing enough to want to cancel but wanting to
wait a bit… nah.
It’s been superceded by the ‘Local’ library (formerly ‘Electoral wards
in the United Kingdom’).
The latter is better because:
- it’s covers all 4 nations, not just England and Wales
- it has electoral wards as well as local authorities which group them,
so there’s more flexibility when choosing an area to broadcast to
We’ve observed people using ‘national’ and ‘local’ during user research.
It has less tongue-twisting ambiguity than county vs country.
But we think that maybe just getting rid of ‘counties’ is enough to
disambiguate them. So this commit just takes the ‘local’ concept.
This commit also gives the libraries and areas new IDs, which means if
we want to rename them in the future it won’t be a breaking change.
It made for a good early demo to show how we could have different
libraries, but we’d don’t think there’s a strong user need for being
able to broadcast to a region of England.
Regions also have the problem that:
- they are ambiguous – both England and Scotland have a region called
‘South east’
- Northern Ireland doesn’t have formal regions
This commit removes the regions library.
If a library has lots of items then the first 3 should be shown, with
a count of how many more there are, for a total of 4 list items:
> a, b, c, and 23 more
If the library only has 4 items then all 4 should be shown, with
consistent use of conjunction and Oxford comma[1]:
> a, b, c, and d
This keeps the lengths of the examples nice and consistent.
1. We use an Oxford comma because it helps disambiguate when an area
itself has a comma or ‘and’ in it, for example ‘Armagh City, Banbridge
and Craigavon’
Some pages should only be shown to users who have permission to send or
approve broadcasts. This commit adds a test to ensure that this is true,
and that we don’t accidentally regress the checks for this permission.
At the moment viewing a broadcast is limited to those users who have
the `send_messages` permission.
This doesn’t match how we describe the permissions on the team members
page
This commit makes it so that any team member can see a broadcast that’s
in any state other than `draft`.
If a library has groups, we should show a link instead of selecting the
group directly.
Then we can give the user the choice of selecting the whole of that
group, or specific areas within the group.
For now the only libraries we have with groups are local authorities,
which group electoral wards.
At the moment they will get a ‘technical difficulties’ error if they
try.
We probably want to do something around letting people self-approve
broadcasts in trial mode, but for now just telling them they can’t is a
better experience than ‘technical difficulties’ (and will probably be
close to what they should see on a live service as well).
Once you’ve created a broadcast you’re taken back to the dashboard. This
feels too passive, and you might miss that the broadcast still needs
approval.
We should be much more explicit that you now need to find someone to
approve your broadcast. Taking someone directly to the page for a
broadcast lets us give more information about the status of the
broadcast and what the next steps should be.
This is an initial, prototype-quality attempt at introducing some kind
of tour for users new to broadcasting. A lot of the users we’re speaking
to don’t have a good concept of what broadcasting means, which is
causing usability problems down the line.
We did a similar thing in the early days of Notify to explain the
concept of message templates and personalisation.
This commit makes the tests for the `broadcast` service permission more
robust by:
- adding coverage of endpoints that have been created since the test was
first written
- checking that the endpoint also responds to a `post` request with a
`403` (or `405` where it is a `get`-only endpoint)
It’s an irreversible action if you do click it, so it feels like an ‘Are
you sure?’ step is sensible. Follows the same pattern for deleting
templates, etc.
