Having a grid in the click target stops the hint
and status text being clickable. This removes it
in favour using flexbox to position the elements
in a similar way.
Includes fallback styles for browsers that don't
support flexbox that positions the child elements
inline, laid out justified, to mimic the flexbox
positioning of justify-content: space-between.
Note: display is overriden on child items under
flexbox so setting display: inline-block is
ignored.
Includes:
- JS to add a class to the heading when the link
is focused
- CSS to apply the enlarged focus style via a
selector which uses that class
- changes to the partial to hook in the JS to
track focus on links and to tell the
updateContent JS to persist the classes added
between updates to the HTML
Now we’ve split the old alerts onto two pages the verbs (‘Broadcast’ and
‘Rejected’) will always be the same for each alert – so they’re not
adding any differentiation.
The specifics of what the datetime means is available on the page for
each alert.
Removing the verbs makes the page a bit less cluttered and makes it
easier to scan down the right hand column.
Two reasons to not hide rejected broadcasts:
- if a broadcast was rejected by mistake then it’s useful to have an
audit of who did that
- it means you can still see old broadcasts without having to leave
in pending-approval, which is dangerous because they might
accidentally be approved
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.
When the list of areas is restricted to half the width of the page it
starts to look pretty higgledy-piggledy when you have lots of areas or
areas with very long names.
To do this I’ve ripped out the table markup in favour of headings,
paragraphs and lists. Probably pros and cons for each, but it was really
hard to do the layout with the content in a table.
Now that pending alerts aren’t in their own section there’s nothing to
label them as pending. So this commit replaces the extra metadata we
show for a pending alert (the name of the person who created it, which
was only ever a reckon) with an explicit label that says it’s waiting
for approval.
Once a broadcast has been submitted for approval it either lives on the
‘Current alerts’ or ‘Previous alerts’ page, depending on where it is
in its lifecycle.
Therefore when clicking into a broadcast from one of those pages the
same navigation item should remain selected.
Because we select the navigation items based on the request endpoint,
this means we need an endpoint for each navigation page, even if the
content of the pages will be the same in both cases.
This commit adds the two new end points, removes the old, single
endpoint and updates links to point to the new endpoint.
Our style for areas is pale blue background with black keylines or bold
black text.
This commit makes the display of area names on the dashboard consistent
with that visual style.
This also means that we’re not truncating the list of areas, which is
appropriate because no one area is more important than any of the
others.
We have a reckon that live broadcasts don’t feel prominent,
consequential or active enough on the dashboard.
This commit adds an animated component, similar to an ‘on air’ indicator
in a broadcast studio, or a ‘recording’ indicator on a video camera.
This is one option for addressing our reckon. We shouldn’t merge this
until we have a better understanding of the problem from another round
of user research.
When we have an approval flow, `pending-approval` will be the state a
broadcast is in between being a draft and broadcasting.
This means it is the earliest stage at which a broadcast can appear on
the dashboard, so this commit adds a new section at the top of the
dashboard to display these broadcasts (since the dashboard is in a
reverse chronological order).
Rather than displaying the scheduled time, the extra information shown
is the person who drafted the broadcast, since I reckon you’ll be coming
to this page because they’ve asked you to approve their broadcast.
The styling of the empty message seems to conflict with the hard-coded
widths added by the `dashboard-table` class. So we should only add the
`dashboard-table` class when there is content we need to control the
width of.
Same technique as we use for other pages that update via AJAX.
I’ve split the page up into separate chunks because the DiffDOM library
we use finds it easier to work out what’s changed when there are fewer
elements/a shallower tree.
