At maximum zoom, the text in the items gets
cropped horizontally.
This removes the padding on their containers to
give them more space and, instead, puts it on the
content items instead.
Left-aligned content still needs some padding on
the left-hand side but centrally-aligned can grow
into the whole space.
This also reduces the padding applied below 420px
width or when the screen is zoomed below 300%.
Above that, our content needs more space between
items but below that, the space allocated to the
content is more important.
Because the ‘All of’ choice appears above the search field, it shouldn’t
be filtered by the search field.
We can fix this by wrapping the sub-areas in a `<div>` and make the
selector more specific.
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
Includes the following pages:
- letter contact (in service settings)
- sms-senders page (in service settings)
- email reply-to (in service settings)
- API key page
Note: the call on the letter contact page uses
the first line of the contact address as the
unique identifier for each button.
Changes the interface so:
- `name` is a required argument
- the heading is only shown if `name` and `thing`
match
These changes reflect a pattern observed in how
the component is used in pages.
It's first worth stating what the `thing` and
`name` arguments are.
`thing` is the type of thing the id is, for
example an reply-to email address.
`name` is which one of that type in the page, for
example the reply-to email address for user 1.
In pages where the id is the only one of its type,
these will have the same value.
When it is the only one of its type in a page, it
always has a heading so this makes the heading
appear based on `name` matching `thing`.
Includes implementation of new code on Reply-to
email addresses page.
The existing code put the live region on the
module element so the id and button were
read out when the state changed.
The report from the Digital Accessibility Centre
(DAC) said screenreader users were confused by the
content changing because it wasn't announced.
These changes attempt to make the state changes
clearer by:
1. moving the live region out into a separate
element so we can better control what is
announced
2. adding hidden text around to the button and text
above (sometimes the id, sometimes the 'Copied
to clipboard' text) to give more context
When the id is copied to clipboard, the button
changes but this is not announced as the
live-region text takes precedence (due to being
set to 'assertive'). Because of this, hidden text
has been added in change 2 to explain what the new
button does.
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`
