Replaced `$gutter` and similar variables such as `$gutter-half` with the
`govuk-spacing()` static spacing function. This uses `govuk-spacing()`
instead of `$govuk-gutter` because `$govuk-gutter` should only be used
for the gaps in between grid columns and we were mostly using `$gutter`
to add more space around elements.
There are other places in the SCSS files where we had hardcoded a
measurement in px which could be replaced with `govuk-spacing`, but this
commit only replaces the existing uses of `$gutter`.
Something in a new version of GOV.UK Elements, Template, or Frontend
Toolkit has introduced a rules which removes padding for the last
column in a table.
This is undesirable in the case of email message previews.
Because the email addresses can get pretty long, and have no spaces in
them, they sometimes break out of their containing box. This looks messy
and causes horizontal scrolling.
The email looks a lot like the normal content of a page (black on white
text, same font, rendered by the browser). It needed differentiating
visually.
This commit adds a border and spacing around the email to separate it
from the things on the page that you’re supposed to be interacting with.
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.
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.
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
If you put, for example, a URL in an email template it can be very long.
This can cause it to overflow its container. This commit forces it to
wrap instead.
We should (and do) keep exact copies of SCSS files that have come from
elsewhere so that we can easily upgrade them. But sometimes they don’t
always pass our linting rules, or throw a lot of warnings, which is
noisy.
This commit:
- moves such files into their own subdirectory
- tells SCSS Lint to ignore files in this directory
Emails can get very long.
When you’re trying to do other things on the page this results in a lot
of scrolling.
This commit truncates email messages to about 3 lines, and adds a JS
toggle which reveal the full contents of the email.
The template for viewing a job was not getting all the variables it needed in
order to display an email template. Hadn’t noticed this before, because email
templates require more variables than SMS templates.
This commit fixes that bug.
The email pattern looked a bit shonky when displayed in a narrower column. This
commit fixes it by making the email’s metadata (eg subject, from) into a table,
which it sort of is. This means that it is more flexible about the size of
container in which it sits.
This commit adds a new page, which appears after a user enters the name for
their new service. It shows how the service name will appear in emails and
text messages.
This means that the new service is not created until after they have confirmed
that the name is appropriate in context.
This has also involved:
- visual changes to the ‘email template’ pattern, which wasn’t very refined
before
- removing a bunch of words from the enter service name page, because most users
don’t read them, and we reckon that showing a preview is a better way of
getting them to understand what is meant by service name
Still to do:
- validating the the generated email address for a service is unique (on the
API) side
- having the API return the generated email address, rather than determining it
in the admin app
If the templates page contains text messages and emails then there’s two ways it
could be structured:
- into two sections, all text messages first, then all emails
- emails and text messages interleaved, sorted by date
I think the second one is better. Imagine a situation where you mostly do emails
but have a few text messages. You’d have to scroll past the text messages to get
to your emails. Every time.
I reckon that the most commonly accessed templates will be the most recent ones.
