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.
