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.
Broadcasting is not a precise technology, because:
- cell towers are directional
- their range varies depending on whether they are 2, 3, 4, or 5G
(the higher the bandwidth the shorter the range)
- in urban areas the towers are more densely packed, so a phone is
likely to have a greater choice of tower to connect to, and will
favour a closer one (which has a stronger signal)
- topography and even weather can affect the range of a tower
So it’s good for us to visually indicate that the broadcast is not as
precise as the boundaries of the area, because it gives the person
sending the message an indication of how the technology works.
At the same time we have a restriction on the number of polygons we
think and area can have, so we’ve done some work to make versions of
polygons which are simplified and buffered (see
https://github.com/alphagov/notifications-utils/pull/769 for context).
Serendipitously, the simplified and buffered polygons are larger and
smoother than the detailed polygons we’ve got from the GeoJSON files. So
they naturally give the impression of covering an area which is wider
and less precise.
So this commit takes those simple polygons and uses them to render the
blue fill. This makes the blue fill extend outside the black stroke,
which is still using the detailed polygons direct from the GeoJSON.
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’
When you click through to the page for a library you see the available
areas in alphabetical order. The examples given for each library should
match this.
The given examples should match the choices offered when you visit the
next page. The choices offered on the next page are either the areas
(when a library is not grouped) or the groups (when a library is
grouped).
This commit makes the examples match the choices by excluding sub-areas,
ie those that have a grouping ID.
This gives the contents of each item more space
which is useful on smaller screens or at higher
zoom levels.
Each item still has a 2px border so is prevented
from its contents touching those of the other
items. They are also flex-items, set to occupy a
quarter of the available space so will removing
this padding will not effect their width.
Now that the data needed to create a `BroadcastArea` is pretty
lightweight because it doesn’t include the GeoJSON we can go back to
putting it in memory when we start up the app, to make the pages load
really fast.
Rough estimate for the size of this dataset:
> 10,000 areas
> Average length of area name = 20 characters
> Average length of area id = 20 characters
> Size of one area in bytes = 20 + 20 = 40
> Size of dataset = 40 * 10,000 = 400,000 bytes = 400kb
I think that even with good indexes, querying the area names from one
table is always going to be slow because there’s so much GeoJSON to scan
past.
This commit splits the data into two tables, one for the names and
grouping IDs and one for the blobs of GeoJSON. So for most pages the app
will never even be looking at the table where the GeoJSON is held.
I don’t know if this is a proper, normalised way of structuring the
data, but it does go brrr.
Rather than querying all the features whenever we look up area(s) let’s
only get them when we need them.
The features are really big blobs of data to pass around, so there’s a
significant performance gain to be had from doing this.
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.
Password managers will try to guess what they should save as a username
by looking at the fields on the page where you set up your password.
When registering from an invite the email address (what we use as a
username) is predefined, and only shown on the page as text, not an
input.
This commit also adds a hidden input field for password managers to pick
up.
Adapted from: https://github.com/UKGovernmentBEIS/beis-opss-psd/blob/master/app/views/users/complete_registration.html.erb#L29-L36