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
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.
I’ve swapped the order of the first paragraph so it joins into one
sentence, and leads with ‘Notify has not broadcast your alert’ which
is the response to what the user has just done. I don’t think we need
to say ‘still’ because the idea is users will swap back and forth
between training and real depending on the situation.
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.
If there is a search term when the page loads, a
statement about the results is added to the
searchbox label.
All subsequent searches are announced via an aria
live-region.
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
Previously attempted in this commit by changing
the element to a <section>:
e815a73233
This broke the updateContent.js, that polls the
JSON endpoint for the partial and updates its
content with changes sent back. From what I could
tell, it broke it because the JS that does the
update gets the diff between the current partial
and the one sent in JSON and applies it to the
current one.
If the notification hasn't completed before the
page loads, the partial added to the page has a
<div> wrapping it, to initalise the
updateContent.js JS. This means the diff ends up
being between elements with a different level of
hierarchy:
Element 1:
<div data-module="update-content">
<div class="ajax-block-container">
...
</div>
</div>
Element 2:
<div class="ajax-block-container">
...
</div>
This seems to work OK when the partial
is a <div>, I assume because it's the same type of
element as the wrapper, but not when it's a
<section>:
Element 1:
<div data-module="update-content">
<section class="ajax-block-container">
...
</section>
</div>
Element 2:
<section class="ajax-block-container">
...
</section>
Because of all this, it's easier to just give it
the role of 'region'.
If a service doesn’t have permission to send international letters but
someone tries to upload a letter with a valid international address we
just tell them that the last line must be a UK postcode.
This is a bit opaque and:
- suggests that we’re not recognising at all that it’s not a UK letter
- doesn’t explain why it must be a UK postcode
This commit adds a new, error message which tells users why their letter
can’t be sent. And hopefully will give them a better idea of how to
resolve the problem, if they really do need to be able to send
international letters.
If it has an accessible name, we're essentially
giving it a grouping role so it should be a
section.
Note: it could also have a role="region" but
sections are a bit more HTML5.
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.
To help people understand that broadcasting is not a precise technology,
we have shown the estimate bleed area on the map.
Because people aren’t familiar with the technology a visual only clue is
not enough. So this commit adds a key to the map, which explains what
the different outlines mean.
It also removes the sticky footer from this page to:
- make the key visible on the page
- make people scroll and review the map before they get to the big green
button
- not reduce the size of the map any further
All other navigations have their selected item as
a link so we should match this.
Includes changes to the pill CSS so:
1. it doesn't use elements in the selectors
2. all the selectors use BEM
I did 2. because I had to change the
classes/selectors anyway, they might as well match
the style GOVUK Design System uses.
