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
Users need to pick a time in the next 24hrs, or send a file immediately.
Rationale for this is a bit lost in time-before-holiday, but generally:
‘Now’ and ‘later’ as the inital choices makes it really clear what
this feature is about conceptually.
The choice of times is absolute, eg ‘1pm’ not ‘in 3 hours’
There’s no point in collapsing […] the email on the single template
page because it’s the only thing on the page.
Users will probably be going back and forth quite a bit to edit their
template and see the changes; they shouldn’t have to expanded it evey
time to check they’ve got the heading syntax right, for example.
The team page was a bit of a mess:
- invited and active tables didn’t line up
- lots of things were wrapping onto two lines
- the empty fields for when a user didn’t have permissions looked broken
This commit splits each row of the table (not actually a table any more)
onto two lines. First line has the user’s info, second has their
permissions and any associated actions.
This commit extends the `ajax_block` component to take a `dict` of
partials, from which it can select the partial matching its `key`
argument and print its HTML to the page.
This means that the same markup is only rendered in one place, rather
than in two (individually in the JSON endpoint and as `include`s in the
parent template).
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.
A long email message needs to be collapsed to only show the first few
lines. The problem is that we were doing this by adding a class with
Javascript, meaning that the email wasn’t being collapsed until the
script in the footer ran.
This caused a jump in the page because the browser was painting the
whole email message, then repainting it once it was collapsed.
This commit takes advantage of the `.js-enabled` class added to the
`<body>` by a script in the `<head>` of GOV.UK template.
This means that the email message is collapsed with CSS before the first
paint of the page, so no jump.
This introduces some complexity in how we determine which emails get the
expander toggle. Because they’re already collapsed we can’t get their
height and work out if they’re long enough to need collapsing.
So we need to take a copy of the message, put it off-screen, expand it,
get its height, then remove it from the DOM. Bit of a faff.
Because of this there’s still a quick flash of the toggle if you see an
email message that’s too short to need collapsing. I think this is the
lesser of two evils—very short email messages will be few and far
between in the real world.
These numbers don’t look very clickable white-on-black.
Blue is the colour of links, so lets see if they are more clickable in
blue.
The same clicking-a-big-number thing is also happening on the activity
page, so this commit also changes the activity page to look the same.
We can filter notifications on the activity page by state.
This commit adds counts to those filters.
This is mainly so that we can consistently do the same thing on the job
page later on.
With sending, delivered and failed all on one line there’s not much
space. When these numbers get relatively big (in the 000s) they can
start mushing into each other.
This commit makes them smaller so that they remain separate.
The first columns of our tables are always headings for the
subsequent columns, even though they go horizontally.
HTML has the `<th>` tag, which doesn’t just have to be used for headings
along the top of a table. So this commit changes the first column to be
a `<th>`.
This then allows us to style these elements differently, specifically
making them 50% wide. This makes pages like the dashboard align more
nicely.
Depends on:
- [ ] https://github.com/alphagov/notifications-utils/pull/40
In research we’ve noticed two problems with the appearance of
placeholders:
1. We are inconsistent about when we display the ((double brackets)).
Sometimes we show them, sometimes we don’t. This doesn’t help user’s
understanding about where the column names in their CSV file come
from, or how they can edit the template to fix any errors.
2. Because they look so different from normal `<textarea>` text, it’s
not immediately obvious that they can be edited just like normal
text. They look more like something that can be dragged/inserted.
So this commit:
1. Makes the brackets always-visible.
2. Makes the text colour of the placeholder `$text-colour`, and only
highlights the name of the ‘variable’, not the brackets themselves.
For the button on the check page, we need to be able to say ‘1 text message’ or
‘55 emails’. We already have the logic to do this on the dashboard (101 text
messages sent), and it’s already in a component. So this commit makes the check
page use the same component.
We have a couple of places now where we want nice lists made from `list`s, eg
- ‘name’, ‘date’ and ‘phone number’
- ((firstname)) ((lastname)) or ((date))
This commit adds a more generic component for doing this, which can handle:
- 1, 2, and n items
- comma (or other character) separated lists
- a conjunction between the last and one-before-last item
- characters to be inserted before and after each item, eg an opening and
closing HTML tag
It also pulls the `list_of_placeholders` component from the breaking change
page, and makes it use the `formatted_list` component under the hood.
This commit refactors the `email_message` and `sms_message` UI components to
take fewer parameters.
`name`, `edit_link` and anything to do with versions are identical for both
text and email messages so I’ve moved them to the pages where you choose a
template or see the versions.
This commit also tidies up the wording and styling of the template history
stuff.
I don’t think that if there’s only one version of the template that it’s
useful to see the created at date.
The auditing stuff only becomes relevant once someone a template has been
changed.
The dashboard looked a bit table-y. This commit makes four main changes:
- show a bar chart (drawn in CSS) for template usage (only shown if
you’ve used more than one template recently)
- only break down template usage by template name, not template type
(because that’s happening with the big numbers)
- change the style of the ‘show more’ links under each section so that
they are all consistent, and a little less busy (one less keyline)
- remove the ‘recent templates‘ title so that the first two sections of
the page group under ‘in the last 7 days’
This commit does two main things:
- adds textboxes to the send yourself a test page, so you can replace
((name)) with ‘Chris’, or whatever your name is
- rejigs the send page a bit to make it clearer what the CSV upload is
for and how to use it
The idea being that, since most users go into ‘send yourself a test’
first, it teaches them about how placeholders work by making them do the
replacing themselves.
When previewing a template on the send page, having the recipient appear
as a placeholder should help reinforce the relationship between the
columns in the CSV and the placeholders.
Then, when previewing a message, having the template populated with the
first recipient’s email address/phone number should reinforce that
relationship again.
Takes the number of emails and SMS fragments sent from:
https://github.com/alphagov/notifications-api/pull/273
Using these numbers it’s possible to show:
- how much of your allowance is left
- or how much you have spent
For now the allowance and rates are hard coded.
Only for users that have manage service.
The big numbers on the home page relate directly to the notifications on
the notification page. So let’s link them. With a _hyper_ link.
This commit actually adds two links, one of which is semantically
correct, and one of which is visually correct, ie makes the whole black
area of the box clickable/hoverable.
This commit:
- moves things around a bit on the request to go live page
- sticks a textbox in there
So when someone click the big green button, we will get a support ticket
that looks something like:
```
From Test User <test@user.gov.uk> on behalf of Test Service
(6ce466d0-fd6a-11e5-82f5-e0accb9d11a6)
---
We’ll send about 1000 text messages in the first month, and then 10,000
text messages per month after that. Usage of our service is about 50%
higher in March, at the end of the tax year.
```
We want to align all our stats to be for the last 7 days.
This means summing up the stats response from the API to make the Big
Number. Previously the big number was counting sent notifications as
successful. This commit changes it to only look at delivered
notifications.
Right now, the API doesn’t have a way of filtering to only show the last
7 days. So for the moment the dashboard will show statistics for all
time.
The upshot of this is that we can link from the dashboard to the
activity page when there are failures.
For users who:
- want to send messages from a template
- want to edit templates
For developers:
- who need to get the ID of a template
This commit mainly cleans up the choose template page so there are less
options, and the options that are there are less wordy.
This means:
- moving ‘send yourself a test’ onto the send messages page, and making
it button
- stripping a lot of stuff out of the ‘send from API’ page, so it’s more
obvious what the template ID is
