Letter templates have (or will have) multiple different editable
regions. I think that the most intuitive way for this to work is to have
- an edit link for each of these areas
- positioned next to the thing to be edited
Again, this isn’t fully hooked up, but since no-one is using letters
live yet this is a good way of getting research feedback and pointing
towards where we want the feature to go.
Uses percentages for the positioning so that the alignment is maintained
on mobile.
We think that sending a test for letters will mean downloading or being
emailed a PDF version of the populated template. While we haven’t
changed the app to do this yet, renaming the button is a good way to get
feedback about it from research.
The links to the right of the template take up valuable horizontal
space. This means that the preview of email and letter templates isn’t
as big as it could be. By making the letter preview bigger it removes
the need to click through to the PDF to see a preview.
Reuses the navigation style used on the API integration page, because I
think it damages consistency to create another new button style.
The find as you type only becomes useful once you have too many
templates to quickly scan visually on the page. I reckon that 7 is the
number where this starts becoming tricky. About 5 fit on the page
without scrolling (on my Macbook).
Not everyone knows how to use `ctrl` + `f`, and it’s not scoped to
just the list of templates.
The template you want to work with is often not the first one in the
list, but ordering by created at is useful for other reasons (mainly
around first time use).
This commit adds a find as you type control which aims to give users a
quick way of getting to the template they want to work with.
When a team has lots of templates the choose template page gets very
long. It gets hard to find the template that you are looking for.
Our initial reckon was that teams would not be giving their templates
very useful names, and therefore a preview would be helpful. What we
have found is that:
- teams actually do give their templates useful names, and refer to
these template names elsewhere
- the previews are less useful for emails and text messages, because
they have so much content (which for emails also makes it harder to
`ctrl` + `f` the template name)
The other problem we found was that this page presented the user with
a _lot_ of options. For each template there were 4 actions, plus the
click-to-preview action for letters, plus the ‘see previous version’
action for templates that had been edited multiple times. It was a very
busy page.
And the final problem (that we recently introduced) was that there was
no way, other than the visual cues, to know whether a template was a
letter, email, or text message.
So this commit strips back the choose template page to be very focused
on finding the right template, by only showing the template name and
type. The user can then click through to a page that shows just a single
template, and perform actions relevant to that template from that page.
This was used on the old product page to do the graphic of three phones
showing three different messages. We don’t have this any more, so this
‘component’ is unused.
Also removes some unused imports which were a hangover from previous
versions of the product page.
- ‘messages sent per month’ is a better description of what will appear
on the page than ‘activity breakdown’
- ‘templates used by month’ instead of ‘this year’ for consistency
I think ‘usage breakdown’ still works for the remaining link – it’s more
than a monthly breakdown, it also breaks down the spend.
Doesn’t need to say ‘by month’ in the `<h1>`s themselves, because you
can see from looking at the page that it’s broken down by month.
If you’re filling out a form then it should be possible to submit it for
as long as you’re logged in. We keep you logged in for quite a long time
now. This is partly for people using assistive tech, who might be slower
to fill in forms, and partly for people who get distracted in the middle
of a task and come back to it later.
The expiry on our CSRF tokens was more aggressive (3600 seconds – 1
hour) than our sessions. This commit sets the CSRF tokens to not expire,
so in effect they last as long as the session.
Also tweaks the config to have CSRF on locally (to replicate production
more closely) and only disable it for tests (because it’s a pain to
grab the tokens in tests).
When we moved the ‘Switch service’ link out of the nav on non-service
pages it removed any obvious way of getting back to your service on a
page that doesn’t have the service navigation (the non-obvious way is to
click ‘GOV.UK Notify’ in the black bar).
So this commit adds a ‘Back to service’ link which does the same thing
as clicking ‘GOV.UK Notify’ (tries to send you to your last-used
service, sends you to the list of services if it can’t).
We keep seeing Chrome:
- autofilling the sign in form with a phone number in the email box
- autofilling the register form with an email address in the phone
number box
This is because Chrome tries to autofill what it considers to be a
_login_. It detects a login as being:
- a password field
- preceded by a text input field
On the sign in page the password field is preceded by a field which is
supposed to receive an email address. On the register page the password
field is preceded by a field that’s supposed to receive a phone number.
I suspect that this is why it’s missing the two up.
The solution to this seems to be to defeat Chrome trying to be clever,
and make it autocomplete based on the `name` of the fields instead (we
name them sensibly, e.g. `email_address`, `phone_number`). The way to
defeat it seems to be sticking a dummy `input` right before the password
field on the register page. This dummy input is hidden from the page and
from screenreaders, so a user should never know it’s there. but Chrome
will autofill it anyway, with whatever wrong value it wants to.
The tour teaches you how Notify works by letting you do a thing and then
showing you the effect of the thing you’ve just done – a text message on
your phone.
This is not as effective if you don’t get the text message quickly. It
breaks the association you make between what you’ve done on the computer
and what’s happening on your phone.
Slow text message delivery can happen if you’re doing a big job. We can
get around this by making your text message use the priority queue.
This was observed in the pilot research session yesterday.
The breaking change page temporarily holds the changes in hidden inputs
on the page. The messages content it gets from the `.content` property
on the subject. This is raw and not transformed in any way, so fine.
For the subject it gets the value from the `.subject` attribute on the
template. For email templates, this will be transformed to highlight
placeholders with `<span class='placeholder'>…`. This means that when
the change is confirmed, it’s this encoded version that gets sent to the
API. Which is bad, because we then save `<span class='placeholder'>` in
the database.
This commit changes the page to look at the `._subject` attribute
instead, which is the internal, untransformed version of the subject.
The support flow was using `yes` and `no` to mean emergency/not
emergency. But not in all places – in one place it was using
`True`/`False` instead.
We were treating anything other than `yes`/`no` as a non-answer, which
means ask the question again. Because of the `True`/`False` thing, there
was no way of the user providing a valid `yes`/`no` answer. Which means
that we just kept asking them the question again and again and they got
stuck in a loop.
For some reason we were rebuilding `new_template` as a dictionary,
without the `placeholders` attribute. This meant that we were never
actually counting the placeholders, just counting the length of `None`
and adding 1 to it.
So this commit fixes that, beefs up the tests, and makes sure that
everything is pluralised properly.
41fa158635 added a proper Jinja filter
for formatting lists, which was better than the previous macro-based
solution.
It didn’t, however, account for HTML properly. It did the default Jinja
thing of escaping everything. Since we render lists of placeholders
by putting HTML before and after each item, this didn’t work (the HTML
got escaped and appeared on the page).
So this commit does the escaping of HTML outside Jinja, in the
user-submitted bits of the input only, then passes the whole thing
through as a `Markup` instance which doesn’t get escaped by Jinja.
