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.
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.
If the notification has come from an API call, the template is the
only thing that exists
If it’s a job, then we need to tell you name of the file. But you can
click though to see the template.
- _Processed_ is all the notifications that we know about, ie sending,
failed and delivered
- _Sending_ is notifications that we have either put into a queue or are
waiting to hear back from the provider about.
The big numbers on the dashboard are a count of all the messages we’ve
processed. So when you click them, the table of notifications you see
on the dashboard should contain that number of notifications.
This also gets the activity page one step closer to being like the job
page:
| Before | After
---------|----------------------------|---------------------------------
Activity | Sending, failed, both | Processed, sending, failed, delivered
Job page | Sending, failed, delivered | Sending, failed, delivered
The link to download a CSV of notifications looks like
`/endpoint?download=csv`. This not not very web idiomatic.
The service manual recommends:
> Only use query strings for URLs with unordered parameters like options
> to search pages.
The CSV is a different representation of the same data, it does not
perform searching or filtering on the data.
The proper way (as we do elsewhere in this app) is to put an extension
on the endpoint to indicate an alternate representation, eg
`/endpoint.csv`
This commit splits the activity page into two pages, one for emails
and one for SMS.
Technically this means moving from having template type in the
querystring and putting in it the URL, eg:
*Before*:
`/services/abc/notifications/?template_type=sms`
*After*:
`/services/abc/notifications/sms`
This commit changes the activity page to only have controls
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.
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.
Row-level errors are:
- bad phone number/email address
- missing data
I think it’s distracting to show these on the page if there’s something more
fundamentally wrong with the file, eg placeholders don’t match.
So this commit makes sure that these error messages are only displayed when the
top-level error says ‘There is a problem with your data’
This commit rearranges the CSV errors (again) to make them geared towards
teaching you how to match placeholders to the column headers.
So the order of errors now is:
1. No phone number/email column
2. Column headers don’t match placeholders
3. Missing or bad data
4. Trial mode
5. Daily limit reached
This depends on:
- [x] https://github.com/alphagov/notifications-utils/pull/39 for 1.
‘How to format your file’ sounds complicated and incidental.
‘See an example’ sounds like something that might be useful if you’re feeling
stuck.
Also makes the list of file formats a list, because it’s a list.
While the blue should help reinforce the relationship between the placeholders
and the column headings, it makes the column headings very busy visually, and
less like column headings. Which make the relationship harder to see. I think.
Now that the example on the breaking changes page looks more like a spreadsheet,
we should do the same thing for the downloadable example on the send page.
When a user adds or removes placeholders in their template we should consider
this a ‘breaking change’ and warn them accordingly.
Implementing this mostly relies on using
https://github.com/alphagov/notifications-utils/pull/37
Temporarily storing the new template until the user confirms that they want to
make the changes in done using hidden fields. This is a bit hacky, but the
complexity of making sessions interact with WTForms was just too much to handle.
This commit also changes the example spreadsheet that we show on this page to
look more like a spreadsheet.
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.
_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.
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.
