There are no changes to appearance of the 'Preview this alert' button or
what it does, but this stops a CSRF token appearing in the query
string when you click the button. We don't need a CSRF token - it's
a simple GET request which doesn't change any data. Before, we had a form
with `method="get"` but because we were using a `page_footer` a CSRF
token was being added.
We can replace both the `<form>` element and `page_footer` with a
`govukButton`. This means that we make a GET request with no CSRF token
without changing the appearance of the button.
The SVG used for the 'X' in the remove area button
has 2 <g> (group) elements, one wrapping
everything and one wrapping the two lines that
make the cross. The first <g> isn't needed and
means that the SVG ends up with 2 accessible
names:
1. the <svg> element gets named with the text from
the <title> because of it's aria-labelledby
attribute referencing it
2. the first <g> gets named with the text from
the <title> because the algorithm that gets the
name looks for any descendent <title>s
This removes the first <g> so only the accessible
name for the <svg> gets announced.
The size and position of the 'X' has deviated a
bit from the design intentions of the original.
The original shared the x-height of the area text
and has positioned to be vertically and
horizontally centered.
These changes assume an x-height of 11px and use
flexbox to center the new 'X' horizontally and
vertically.
This also tweaks the visual state when focused and
then hovered so matches other buttons without
breaking the design.
The text never had underlines like our other
link-button components so always looked like
buttons. If they look like buttons, they should
act like them too and have those semantics.
This give them a role of button and uses the class
and data attribute for the button component from
GOVUK Frontend to make them work like one.
These changes include a fair amount of styles to
override those the govuk-button class brings in.
I've tried to mark those ones to at least make
that obvious.
The current link button for removing an area is
created using a psuedo element with an 'x' as
content.
The inline box for the 'x' overlapped its parent.
This is visible in high contrast mode, breaking the
parent's border. Despite existing in CSS, the 'x'
is also announced by screen readers, which is not
what we want.
This changes it to be an inline SVG with a role of
image. It doesn't require as large an inline box
so doesn't cause visual issues in high contrast
modes. It also means we can set it's label similar to
how you would an image's alt text, giving us
control over what is announced by screen readers.
This commit also includes some extra CSS,
targeting high contrast modes, giving the
link button the following when viewed in those
modes:
- a complete border so it is
distinguishable from the list item
- a focus style
The page_header macro includes an optional back link. Since the
page_header is always used inside `<main>`, where the back link should
not be, this stops setting the back link in the page header and instead
sets it in the new `backLink` block.
At the moment the admin app expects all broadcasts to have a template,
and expects the content of the alert to come from the template.
This commit makes it so those pages can still get a `Template` instance,
but populated with content straight from the `content` field in the
database.
We hide the map inside a details element.
Because the map has such a strong shape I don’t think it needs the grey
border to contain it. This commit removes the border, and adjusts the
spacing to group things by proximity alone.
By removing the border and associated gutter we can give more space to
the map, and make the page look less busy.
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
We have a bunch of stuff for doing lat/long transformation in the
`BroadcastMessage` class. This is not a good separation of concerns, now
that we have a separate class for dealing with polygons and coordinates.
This commit does two things:
- uses our new polygon-simplifying library to process the polygons
before storing them, rather than processing them in real time
- stores only the polygons in the database, rather than the whole
GeoJSON feature, because we don’t need any of the other information
about the feature
Simplifying polygons means reducing the number of points used to render
them. This commit implements simplification such that, for any given
input polygons, the combined point count of the simplified polygons is
less than 100.
When simplifying the polygons we are trying to get the smallest number
of points while meeting these two rules:
1. No part of the area the user has chosen can be cut off
2. The area of the simplified polygon should be as small as possible
This commit introduces two techniques we weren’t using before:
1. Dilating and eroding the area to fill in concave details of the
shape, like inlets and harbours[1]
2. Making the simplification threshold proportionate to the perimeter of
all polygons, so bigger and crinklier polygons get more
simplification applied
It also shows the estimated bleed as a separate polygon. This lets us
make it bigger (so it’s more closer the the approximate bleed) without
having to send a bigger area to the CBC and compounding the amount of
actual bleed.
1. Inspired by this blog post about ‘removing the crinkley bits’ from
Vancouver Island:
http://blog.cleverelephant.ca/2010/11/removing-complexities.html
Adding left margin to the button meant that when it wrapped onto a new
line it didn’t align flush with the left edge of its containing column.
Instead we can:
- move the link outside the list (which is better semantically anyway)
- then add the margin to the last item of the list (which is now the
last selected area, not the link)
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.
This commit removes the code the puts areas into the session and instead
creates and then updates a draft broadcast in the database.
This is so we can avoid session-related bugs, and potentially having a
large session when we start adding personalisation etc.
Once a broadcast is ready to go it is set to `broadcasting` straight
away with no approval. We’ll revisit this as we learn more about how
users might want to manage who can create and approve broadcasts.
The tests are a bit light in terms of checking what’s on the page, but
clicking through the pages is probably good enough for now.
This is borrowed from an earlier prototype, and is meant to be temporary
– something better than just plain text.
Text in generated content isn’t always announced by screen readers, so
we should definitely move away from that once we understand what text
will be shown on the phone and where it comes from.
Gives them some colours, borders and stuff to make them visually
consistent with the rest of Notify.
The idea is the tags and polygons have a similar affordances (i.e.
border thickness, colour) to visually link them and imply that they are
two representations of the same thing.
So you can check you’ve chosen the right areas, and to give you a clear
idea of where the boundaries of an area are.
The Javascript and CSS for the map is only loaded on this page because
it adds quite a few kb, and we don’t want to be sending assets to the
majority of our users who will never see them.
These are just so we have some pages to click through for now. They
don’t use real templates, or any of the broadcast stuff from the
database.
But I think it’s useful to get some skeleton pages in first so that we
can see the map etc working in production, then build on that, without
having to do it all in one mega PR.
For that reason there are two short term things I’ve done in this commit
which should be revisited soon:
- no tests for the endpoints
- data about which areas are selected is stored in the session
