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.
Changes those fields in the following forms:
- FreeSMSAllowance
- ProviderForm
- ProviderRatioForm
- ServiceDataRetentionEditForm
Includes changes to templates that use this form
and associated tests.
Changes those fields in the following forms:
- DateFilterForm
- RequiredDateFilterForm
Includes changes to templates that use this form
and associated tests.
Changes its StringFields to GovukTextInputFields.
This change also affects NewOrganisationForm,
which inherits from RenameOrganisationForm.
Also includes changes to templates that use this
form and associated tests.
Makes it inherit from GovukTextInputField.
Changes to govuk_field_widget to allow the value
attribute to be set by passing a value keyword
argument to the __call__ method.
Includes changes to templates that use this form
and associated tests.
We had two identical callback form classes. One for delivery callbacks
and one for inbound sms callbacks. Since they did not differ I consolidated
them into one CallbackForm class that they both inherited from previously.
I also substituted field classes for this form with new fields
that cooperate with gov uk frontend.
ListEntry component uses FieldList field to group
textboxes. Textboxes can be text inputs, email fields
or international phone number fields. This converts
all field-lists to use:
- GovukTextInputField
- GovukEmailField
- InternationalPhoneNumber
Affects these forms:
- OrganisationDomainsForm
- GuestList
Also changes to related Javascript:
Update list-entry JS tests to match new HTML
Updates the HTML the JS operates on in the test
(a fixture representing the HTML in the page on
load) to match the new GOVUK Frontend we are
generating.
Make list-entry JS work with GOVUK Frontend HTML
The existing list-entry JS did a few things that
clashed with how the new HTML works:
- added a 'input-' prefix to the id attributes
of all text-inputs
- did not make its name and id attributes values
match
The new HTML has id and name attributes that
match so these changes remove the prefix for id
attributes and makes them match the name
attribute.
To understand these changes, it is useful to
know how the values for id and name attributes are
generated:
1. the id attribute for the component element is
stored
2. the 'list-entry-' prefix is removed and the
remainder is used to generate ids
For example, if the component's id is
'list-entry-domains', the id will be 'domains-1',
where the text-input is the first one.
This also adds some logic to the HoganJS template
to make the value attribute optional, so it is
only added if it has a non-null value. This
matches the behaviour of the text-input component
used in the new list-entry component.
Also change whitelist references to guestlist in tests
- we forgot to do it earlier, when we moved from calling this
feature whitelist to calling it guestlist.
Changes its:
- StringFields to GovukTextInputFields
- EmailFields to GovukEmailFields
Includes changes to templates that use this form
and associated tests.
Updates StringField to GovukTextInputField.
These changes also affect the following forms that
inherit from BaseTemplateForm:
- SMSTemplateForm
- EmailTemplateForm
Includes changes to templates that use these forms
and associated tests.
Changes those fields in the following forms:
- SearchByNameForm
- SearchUsersByEmailForm
- SearchUsersForm
- SearchNotificationsForm
Includes changes to templates that use this form
and associated tests.
Changes those classes so they have the same
interface as a GOVUK field when instantiated and
render GovukTextInputField HTML.
Includes changes to templates that use this form
and associated tests.
Changes those fields (and sometimes also regular text input fields)
in the following forms:
- LoginForm
- RegisterUserForm
- ChangeEmailForm
- FeedbackOrProblem
- AcceptAgreementForm
- ChangeNameForm (only name field here, but used in the same template
field as ChangeEmailForm here: app/templates/views/user-profile/change.html)
Also includes changes to templates that use this form
and associated tests.
