rather than creating a job, after entering the placeholders, you now
send a single notification. This means we don't clog up s3 by creating
lots of one line CSV files.
We’ve made a few changes to the tour recently, without changing the
help text on the left hand side of the screen. So the stuff you see on
the right side of the screen doesn’t quite sync up any more.
This commit adds an extra, introductory page that just shows the
template and a next button, which better matches the ‘every message
starts with a template’ help text.
Works similarly to the delete template flow, because it’s a destructive,
one-way action.
Not on the edit template page, because it’s not something you want to be
considering every time you’re editing a template. And we saw that people
couldn’t find the delete button when it was on this page.
Adds a bit more CSS for the `dangerous` banner type, because the content
here is quite complicated. Breaking it into a list helps, but the
spacing didn’t look right, so needed some tweaking.
Can ship independently of the code that shows the redaction, but needs
the API first.
There are a bunch of services that just have one text message template
and one email template.
In this case the template navigation is essentially the same as the
list of templates – a user can just differentiate by looking at the two
templates. Adding the nav would just be noise in this case.
There are lots of services that only send emails, or only send text
messages. For these services, being able to filter the list of templates
but type is pointless – it won’t cut the list down at all.
This commit adds some logic to only show the navigation if the service
has some variety of template types.
When users are trying to find a template there’s a fair chance that they
know whether or not it’s an email/text message/(letter) that they’re
looking for.
Making them scroll past a whole bunch of templates of a different type
means it will take them longer to find the template they are looking
for.
We already have search on the templates page, but this is only good for
where they can remember the name of the template. This will be
sometimes but not always.
This commit adds some navigation to filter down the list of templates to
only show one type at a time. By default it will show all templates. It
adapts the pattern we use for filtering notifications by
sending/failed/delivered, but without the counts of how many things are
in each bucket (I don’t think there’s any value in knowing you have X
text message templates; on this page you only really care
about the one template you’re looking for).
_Note: required re-arranging the functions in `templates.py`. The route
for `/template/:uuid` needs to come before the route for
`template/:string` otherwise Flask tries to interpret a template’s ID
as its type.
Generally, bigger click areas are better[1], as long as they don’t cause
ambiguity or accidental clicks.
This commit expands the clickable area of tables where the left-hand
column is a link to include the meta information under the link.
We can’t make the whole row clickable, because sometimes we have links
in the right hand column which go to a different place
This commit also removes the CSS for `.spark-bar-label`, because these
elements are visually identical to `file-list`s now.
1. https://en.wikipedia.org/wiki/Fitts%27s_law
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.
Showing the template on the job page was semi-useful when you couldn’t
see the contents of each individual message. It was still a bit weird
because it just showed the template, never the actual messages that
went out, with the placeholders.
Now that users can click through to see individual messages, and can see
a short preview of the content on each row I think we can safely lose
the template preview on this page.
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.
‘Report’ jobs are what we used to have for one-off messages. The page
for a report job doesn’t contain any extra info from what’s on the
notification page. We will still have ‘Report’ jobs while we transition
to sending one-off messages through the API. So while we still have
these jobs, let’s hide any links to them because they’re not useful
pages.
If a notification has been sent from a job then that’s important context
to know about it. So we should surface that information on the page.
It also gives users an easy way of going back, if that’s the page
they’ve come from.
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.
Having a file name for single messages made sense when they were called
‘Test message’. They made a bit of sense when single messages still had
a file, which had to be called _something_.
Now that individual messages don’t come from a file, and don’t land you
on a page that looks like a ‘report’.
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.
The counts on the notification page will only ever show 1 thing. Which
feels like overkill, especially if you’re only sending one-off messages.
It’s also confusing when you come from the job/activity pages which
have one set of numbers to then be confronted with a different set of
numbers.
The important stuff on this page is:
- what the message was
- some meta information about it
Sorry Leo 😢
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.
Generally, bigger click areas are better[1], as long as they don’t cause
ambiguity.
This commit expands the clickable area of links to templates to include
hint text underneath which states the type of template.
1. https://en.wikipedia.org/wiki/Fitts%27s_law
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
Not good to be storing people’s phone numbers in browser autocomplete.
And increases the chance of accidentally sending the wrong thing to the
wrong person.
Serializing the search box form is bad, because the AJAX thing submit
any changes that the user makes to the contents of the box. This results
in unexpected behaviour.
