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.
Splitting the dashboard into multiple sections was confusing, and people
sometimes mistook the headings as labels, especially when a section was
empty. It just wasn’t clear what the hierarchy of the page was.
This commit combines the current and pending broadcasts into one list
on the dashboard. Previous broadcasts have already moved to their own
page.
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.
The following issues were raised with the table
that replays CSV data to users:
1. the table could not be located by low vision
users using the reflow technique
2. the content should be presented in a single
column when the reflow technique is used
Number 2. came from the Web Content Accessibility
guidelines (WCAG) success criteria 1.4.10 Reflow.
I wasn't able to reproduce number 1. so asked the
Digital Accessibility Centre (DAC), who tested it
originally, for help. Tom Shaw from DAC kindly
retested it and found the problem was gone so I am
considering it fixed.
I am treating number 2. as a misinterpretation of
the success criteria as it lists data tables as an
exception to the rule:
"Except for parts of the content which require
two-dimensional layout for usage or meaning.
...Examples of content which requires
two-dimensional layout are images, maps, diagrams,
video, games, presentations, data tables, and
interfaces where it is necessary to keep toolbars
in view while manipulating content."
The full page is here:
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
The accessibility statement was last updated on 9
October 2020 but without the 'last reviewed' date
being updated.
The changes were contained in this pull request
which was merged the same day and reached
production at 2.13pm.
https://github.com/alphagov/notifications-admin/pull/3677
The most important part of the broadcast is what content was sent where
(and when).
This commit reduces the priority of the ‘meta’ information, like who
prepared and approved the broadcast. I also think that the ‘end’ time is
a lot less important than the start time, since most people will receive
the alert at or near to the start time.
This then matches the order in which the message is drafted, first the
content, then the areas. It also matches the order we’re going to have
on the new dashboard.
When we converted textboxes on Notify to govuk-frontend design system
style with @tombye , we did not remove the imports.
This work is now done in this commit.
Some things that will still stay in our repo for now:
textbox macro in our components folder and associated css
textboxes which are really textarea fields (🤷 how do they work)
textboxes on the styleguide page
We should revisit this when we convert textarea fields
to govuk-frontend.
The idea was that this would be a place to document all the design
patterns used in Notify. However it hasn’t been kept up to date, and,
looking at the `git blame`[1] no new patterns have been added for 5
years.
I think it’s better to get rid of it than have to keep maintaining
something which is inaccurate.
1. 64aa0d359c/app/templates/views/styleguide.html
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.
The dashboard for normal services is quite general, because it tells
you a bit about channels, templates and spend.
What is now the dashboard for broadcast services is much more specific,
therefore less like a dashboard. We can reflect this by giving it a more
specific name. This should reduce the amount of navigation surfing
people need to do in order to find the thing they’re looking for.
Previous alerts are much less important than ones that are live or
waiting for approval.
Therefore we can make the dashboard more focused by moving previous
alerts to their own page.
This prefixes everything to do with areas/the map with `area-list`, so
from looking at one element you know which `.scss` file will contain the
relevant code.
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.
I’ve never liked the style of the selected areas on the preview of a
broadcast message. They were a compromise, taking what’s on the map page
and giving it a shaded background so it looks less like a text box.
The trouble is all these stroked elements jumbled together made the page
look very busy. I think it can be a bit calmer if they look more like
the ‘tag’ component[1] from the Design System, which only uses shading.
Going for black text not blue, because it’s one less piece of visual
differentiation – again, trying to keep the busyness level down.
1. https://design-system.service.gov.uk/components/tag/
The Digital Accessibility Centre (DAC) reported
that it was confusing that focus was moved to the
templates and folders search textbox when the page
loaded on the templates page.
We noted that this issue wasn't reported on the
page where you enter your SMS 2-factor code.
From this, we determined that pages with a single
task could benefit from focus moving to the part
of the page that lets you do that task.
Because of this we:
- found all the pages we shift focus on when they
load
- kept it for pages where the focus shift is
important for what users do on the page
- removed it for all other pages (including
templates)
The work was completed in:
https://github.com/alphagov/notifications-admin/pull/3622
This work also changed the label of the focused
element as a hack to get the page title read out.
This normally happens on load to indicate a
navigation has happened but didn't in Voiceover
when we focused an element on load.
After testing with JAWS and NVDA we found only
Voiceover does this. As Voiceover has the smallest
market share, and navigation can be inferred by
other mean, we removed it in:
https://github.com/alphagov/notifications-admin/pull/3673
That was deployed today.
