Because we’re be grouping jobs under their parent contact lists it’s
good to have some information ‘scent’ to help people find their jobs,
ie by clicking into a contact list. It also lets you see which list have
been used more than others, maybe because the update hasn’t been sent
to that group of people yet.
The hint text under uploads always says when they were used. For contact
lists this is a bit more complicated, since they can:
- never have been used
- been used multiple times
This commit makes use of the new fields being returned by the API to say
determine when these messages are relevant. They also let us
differentiate between a contact list that’s never been used, and one
that has been used, but not recently enough to show any jobs against it.
It’s a bit unintuitive that starting a job from a contact list makes a
copy of the file, which has no relationship to the list it was copied
from. This is more of an implementation detail, rather than something
that comes from people’s mental models of what is going on. Or at least
that’s what I hypothesise.
I think it’s clearer to show jobs that come from contact lists within
the lists that they were created from. By naming the jobs by template
this gives a clearer view of what messages have been sent to the group
over time.
This is no longer happening with the NVDA screen
reader, which had the issue, when testing in
Outlook.
The hack added as a temporary solution has now
been removed. It went live on 19 November 2020 at
2.20pm.
Proof of concept for the GovukRadiosField class.
Includes the removal of the a DataRequired
validator. This doesn't seem to be needed as the
RadioField superclass catches any submissions
without any data from field.choices in its
pre_validate method (which also outputs the
correct error message).
The _Long text messages_ section of the page is probably the most relevant place to talk about this – so users are aware of the double-characters before they see the table of message lengths.
Live services shouldn't be able to request to go live again. Once a
service is live we remove the option to go live from the Settings page,
but we still link to the page to request to go live from other places
e.g. the 'Get started' page. As a result, we've seen some services make
another request to go live when their service has already been live for
months - this change will stop that from happening.
The `.send_from_contact_list` function redirected to `.check_messages`
with `original_file_name` in the query string. Contact lists already
have `original_file_name` as part of their metadata, so we can stop
sending it in the query string and use the metadata instead.
You might alternate between training mode and live mode. It’s not like
normal Notify where you start in one mode and then transition out of it
– which is what ‘still’ implies.
I'm mainly making this change because it's useful
for the CSS that styles the hint text when the
link is focused for the link to have no parent
container.
That being said, there isn't really enough content
underneath these headings to justify them as it is.
I've wrapped them in a list instead because:
- they're structured like a list
- we already called them a `template-list`
This commit also replaces the `message-type` class
on the paragraph below where the headings went,
for consistency. It also removes the CSS for that
class as I couldn't find anywhere else that used
it now.
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.
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
