At the moment we are manually cancelling letters for people when they
ask us to. Once’s we’ve done this there is no indication that it’s
happened except for the date going red on the list of letters.
This commit adds some error messaging and styling to show when a letter
is cancelled.
Letting people cancel their own letters will be a future enhancement.
This will stop us repeatedly forgetting to add `novalidate` and
`autocomplete='off'` to our forms (which is how most of them are set
up).
It uses sensible defaults, based on how we most-commonly configure
forms:
- most of our forms are `post`ed (but this can be overridden)
- `autocomplete` should only be enabled where it makes sense, otherwise
it’s more annoying than useful (but this can be overriden)
- we should never be using HTML5 form validation because our own error
styles and messages are better
If a message has been sent with a test key it’s a bit confusing to just
say ‘Delivered’ on the page, because it hasn’t gone to anyone’s phone.
So this commit adds a bit of hint text to disambiguate what ‘Delivered’
actually means in this context.
Commented out the link to documentation because sending a document is only described in the Python documentation at the moment.
Discussed with Chris H:
Added a line asking users to contact the team. Support can explain the situation if we get any requests. We'll remove this and reinstate the original line once this feature is available across more API clients and the documentation is updated.
The main task that we think ‘caseworker’ users do is send one off
messages.
So this commit:
- makes sure users who don’t have the `view_activity` permission (ie
not ‘admin’ users) can still send messages
- adds navigation so that these users have a place to go from which to
start the process of sending a one off message
We’ve supported this for a while but don’t tell anyone how to do it.
This commit also alters the spacing of things so the description groups
better with the example.
For text messages/emails it makes sense for ‘sending’ to be gray and
‘delivered’ to be black. But since we don’t show sending/delivered for
letters it doesn’t make sense for the text to change colour.
We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
There was a lot of repetetive wrapping code being repeated for every
conditional block in these files. Let’s wrap it around the whole
conditional bit once instead.
The sending/failed/delivered thing:
- doesn’t map to the actual states of letters
- doesn’t respond quickly enough to give you feedback that something is
happening (because "sending" doesn’t even go to "probably delivered"
for a few days)
This commit replaces these 4 boxes with some more useful information:
- one number – how many letters were in the job in total
- when we estimate that the letters will be delivered
The status for each letter in a job will be the same for every single
letter (at least until we start dealing with returns).
It’s redundant to show this information over and over again. This commit
removes it.
This message is meant to indicate that generating the report is still in
progress. Saying 100% contradicts this because 100% sounds like
‘complete’.
Reason this is happening is because rounding 99.5 to 0 decimal places
gives you 100.
So let’s make sure it never gets above 99.0
they're currently expecting a RecipientsCSV object - but we won't
always have that available if we're handling a single notification.
So make the partials take generic variables, and then use a jinja with
block to pass in the correct values from either the check csv page or
the check notification page.
Additionally set the notification check page to show errors nicely -
hide the send button if there were problems, and replace the header
Most of our tables are now lists which have:
- a thing you click on
- some secondary info about that thing underneath
- some extra numbers/status on the right hand side
Since these are so similar, they should share the same pattern, which
this commit does (using the `file-list` pattern).
Visually this means:
- the secondary text on the inbox becomes grey not black, for
consistency
- the status bit of the notifications tables bottom align like the
status of messages in the inbox
These both seem like OK changes to make for the sake of consistency.
We’ve removed the template on the jobs page, so you can no longer see
which template a job is about to be sent with.
This is removing information which might enable you to undo a costly
mistake.
I don’t think we need to bring back the whole template – giving its
name, and a link to it meets the need just as well.
In tables where we show rows and rows of information we used to give
some meta information about the notification, or at least as much as we
could give in the very limited space available.
This information is now on the notifications page, so the information we
show in these tables should just be whatever helps users identify the
right message. I reckon that this is:
- the content of the message for text messages
- the subject for emails and letters
This also makes these pages consistent with:
- the inbound SMS page
- the way the people’s inboxes work for their text
messsages/Whatsapps/emails
For consistency’s sake this makes the job page work the same way. It may
be slightly less useful here because on the job page every message is
sent from the same template, so will have broadly the same content.
The meta info about a notification (who sent it, when they sent it)
won’t ever change, so there’s no need for it to reload it using AJAX.
Putting it above the message and under the `<h1>` makes it match how
this information is displayed on the job page.
On the job page this information is bold, but visually the job page is
using too much bold now (nothing is emphasised/differentiated if
everything is bold). So this commit also makes this line of info regular
on both the notification and job pages.
Since we’ve removed the table of notifications from the single
notification page there’s no way of knowing the status of a
notification.
This re-adds it in a way that’s similar to how it looks on inbound
messages.
We have a page for individual notifications now.
On the job and activity pages each row of the table represents an
individual notification. So it makes sense for these things to be linked
together, so that a user can navigate from one to the other.
This will make more sense once we make some more changes to the
individual notification page.
Status code was overcomplex, given how we control the inputs. Now, it
expects a single value, rather than a comma separated list, and if you
give something it doesn't expect it just returns all. Note, it won't
select the correct box - but if you've been manually editing the URL
that's your own problem ¯\_(ツ)_/¯
Also, as this page will only ever be shown from the tour (tutorial),
it doesn't need some non-help things - such as the download csv button
and associated endpoint.
completely mimicks the job status page, and as such, all the code and
templates have been taken from the job page. This page performs
exactly the same as the job page for now
* total, sending, delivered, failed blue boxes (though they'll just
read 0/1 for now.
* download report button (same as with job download, except without job
or row number in file)
* removed references to scheduled
* kept references to help (aka tour/tutorial) as that'll eventually
change over from a job to a one-off too
This is a term that one of our research participants used to describe
the big bold text that starts each letter. I think it’s quite a nice
plain english term for it.
Also changes the formatting guidance to use the word heading instead of
title, for consistency.
This page is not the place where you edit the contact details. Nor is
it the place where you can preview changes to the contact block. In
research users never found the link to get from this page to the edit
contact details page. So this commit removes it.
When you’ve sent message(s) using a template, often the next thing you
want to do is go and send the same template again, or edit it.
Currently there’s no way of getting to a template from a job except for
going back to the list of templates and re-finding it.
This commit adds a link at the bottom of the job page that gives you a
shortcut back to the individual template, where you can find actions
like edit/send/etc.
Currently it’s not possible for a screen reader user to know which
financial year they’re looking at. From the accessibility report:
> The financial year links are contained in a navigation region -
> tabbing or arrowing through only reads out the links, not the main
> information of "2016 to 2017 financial year" - that information is
> vital for understanding the page content.
This problem also applies to other pages which use the `pill` component,
which is effectively tabbed navigation (that reloads the page rather
than showing or hiding content on the page).
There are specific ARIA attributes that can be used to mark up a
navigation as being tabbed. This commit:
- adds those attributes
- makes the selected ‘tab’ visible to screenreaders and keyboard
focusable
- adds a visual focus indicator to the selected tab
- adds `id`s to the parts of the page that are controlled by the tabs so
that they are labelled as such
This also means changing the pill component from being a `<nav>` to a
`<ul>` because `tablist` is not a valid `role` for a `nav`.
Mostly follows the example here:
http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml
Implements https://github.com/alphagov/notifications-utils/pull/81
Handles addresses as multiple columns:
- in ‘Send yourself a test’
- in example CSV files
- in validating that a CSV file has recipients (eg at least an ‘address
line 1’ and ‘postcode’ column)
- when showing the contents of a CSV file
As few UI changes as possible, once we have the thing working end-to-end
we can think about how the UI might need to work differently.
