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
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.
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
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.
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.
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
Friday at 4pm is easier to understand than 14 October at 4pm, especially
when the UI you’ve used to choose this time has talked about days of the
week.
This commit changes the tables of notifications from 3 columns to two
columns. This is so the text has more room, so it doesn’t start
overlapping.
It also makes sure that if the recipient gets really long that it will
be cut off with an ellipsis, rather than overlapping…
I hypothesize that if a notification fails you probably don’t care when
it failed, just that it failed.
If you schedule a job you might change your mind or circumstances might
change. So you need to be able to cancel it. This commit adds a button
on the job page which hits the `…/cancel` API endpoint for a job.
The diffDOM Javascript sometimes throws an error if it can’t calculate
a diff between the original content of the page and the updated HTML
delivered via AJAX. The problem seems to be when there’s not one,
consistent top-level element for it to base its calculations on.
This commit:
- makes sure that all AJAX-delivered partials have a wrapping `<div>`
- that this `<div>` has a consistent class name to make it clear why
it’s there
If a job is scheduled then we can’t show the notifications yet, and the
progress report will stay at 0%.
In their place we should show what time a job will start.
Later on (when the API is ready) this area of the page should also show
a cancel button.
On the dashboard:
- adds a new ‘in the next 24 hours’ section to the dashboard which lists
upcoming jobs
- tweaks some spacing on the dashboard so that it doesn’t look like too
much of a mess
- don’t show scheduled jobs in the table of normal jobs
On the jobs page:
- don’t show scheduled jobs
Similar to how we do it on the check page, we should indicate if there
are more results than we can show. No-one’s really complained about the
absence of this, but it can’t hurt.
The CSV report isn’t very useful until it has all the rows from your
original file. So we shouldn’t show you the link until all notifications
have been created.
Until this point, it’s useful to know how much longer you need to wait,
so this commit adds a percentage count of how much of the file has been
processed.
When we say ‘delivery information is available for 7 days’ you have to
infer _when_ the seven days starts. When you come back to the page it
still says ‘available for 7 days’ even if you only have a day left to
download it. This is confusing.
This commit changes the text to be relative to now, eg ‘available for 7
days’, ‘available for 1 day’.
The date is counted to midnight on the seventh day, which is when the
data is actually deleted.
The previous text didn’t make it clear _what_ you were downloading as a
CSV file, you had to infer it from the context.
And the fact that it’s a CSV file is immaterial, it’s the data you care
about, not the format.
If something has failed and you don’t know why, you should be able to
find out why. Let’s try adding a link to the page explaining why, so
it’s not just buried in the footer.
Our templates are a littered with `request.args.get('help', '0')`.
This commit refactors these into a single helper method, which can be
used by the view functions, then passed to the template.
This makes the templates cleaner, and should make it easier to refactor
`help` out of the query parameters entirely in the future.
This is less repetitive than typing out the HTML with all its attributes
every time.
It also lets us wrap up the idea of ‘finished’ as a parameter, so the
AJAX code will only be initiated when it’s needed, eg if a job is still
processing.
Previously, the AJAX update for the dashboard was returning a big blob
of JSON with one key.
This commit splits it up to return:
- one key for each section of the page
- each containing a smaller chunk of HTML rendered from a partial
The jobs page was already working this way (pretty much) but just needed
a little tweaking to get it the same.
We can filter all notifications by status already. This commit reuses
the same code to filter the notifications for a job by status.
This means that, visually we can show the count on a job the same as
we do for all notifications, which is similar to how we show the counts
on the dashboard, so hopefully it feels like a bit more of a solid
thing.
This also applies to CSV downloads and AJAX updates, which will inherit
any filtering that their parent page has applied.
We have tables listing notifications on:
- the job page
- the ‘activity’ page
Previously that had subtly different information, in a different order.
This commit makes them exactly the same.
Sending notifications don’t have an `updated_at`. This causes the time
formatting to throw a wobly, because it doesn’t expect `None`.
This commit changes the template to also look for the `created_at`,
which all notifications have.
_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
