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
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
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`.
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)
error pages
The skiplink in those pages is in the error summary
at the top. In this case, it seems redundant
because:
- it jumps to a section of the page just below it
- the section it would jump to is the only error
on the page
Because of this, and because The Digital
Accessibility Centre (DAC) reported that the
skiplinks in these pages may not be needed, we
decided to remove it.
This commit also adds a prefix to the table caption to
indicate that it only contains the errors from the
CSV, not the rest of its contents.
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.
This shows the green banner with a tick when cancelling a user's
invitation to a service or organisation. The accessibility audit noted
that 'When cancelling an invite a new page loads, however, there is no
immediate indication that the invite has been cancelled.'
In order to display the invited user's email address as part of the
flash message, this adds new methods to the api clients for invites to get
a single invite.
sms sender, email reply to, letter contact blocks.
These are all cached within template, under `template.reply_to` - if the
template doesnt have a specific default, then that field stores the
service default. So when service default changes, we need to clear the
template cache so that it is updated to reflect that.
We already use this pattern for deleting the template cache for a bunch
of templates in `template_folder_api_client.move_to_folder`
Since broadcast services can only have one type of template we probably
don’t need to disambiguate what kind of template you’re creating.
And you’ve just come from a page where the button says ‘New template’,
without the choice of radios after, so it’s nice for the page title to
match that.
