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.
Although we integration test the pages that depend on these, it’s
probably a good idea to unit test them as well, to make sure, for
example, that all the different statuses are counted when working out
how many messages have been sent from a template.
- ‘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.
Everything is fine and happy locally and on Jenkins.
Getting a `cannot import name viewkeys` error on AWS.
Based on some Googling, it’s possible that this will fix it.
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).
Gulp was spitting out a lot of noise about stuff being out of date. The
cause seemed to be our outdated version of Gulp SASS. This commit
upgrades Gulp SASS to the latest version.
Changes:
---
https://github.com/dlmanning/gulp-sass/compare/v2.3.1...v3.1.0
This is a breaking change because one of the underlying libraries
includes a breaking change. But looking at their release notes, it
doesn’t seem to affect any SASS features that we’re using:
https://github.com/sass/libsass/releases/tag/3.4.0
Problem
---
You make a minor typo, save the file and your Gulp process dies without
you realising. You then spend 5 minutes trying to work out why your
changes aren’t appearing, no matter what edits you make.
Solution
---
Catch errors raised in processing the JS/SASS files and log them,
without killing the process.
How
---
Use a handy plugin called
[Gulp PrettyError](https://www.npmjs.com/package/gulp-prettyerror).
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.
