Not sure what about the new radios is causing this, but they no longer
expand the size of the container, causing an overlap.
The fixed height was originally for performance reasons, but removing
it doesn’t seem to cause the page to jump around on load, so I think
it’s OK.
GOV.UK Elements changed tables to be a larger font size here:
https://github.com/alphagov/govuk_elements/pull/185
This is good in principle (and a lot of our tables are 19px already).
However, the ones that aren’t are still 16px because there’s a lot of
info to fit on the page (eg when previewing someone’s CSV file).
Not sure why we were doing this. But as part of the Elements upgrade
our back buttons got bigger (because they weren’t constrained by the
line in our `app.scss`) but any green submit buttons stayed smaller in
height, so didn’t line up.
This commit removes the override, so all buttons have the size that
Elements intended.
The Elements CSS was making the `label` and `input` of disabled radio
buttons `opacity: 0.5`. This was resulting in text that was:
- too pale, especially where we were nesting 16px ‘hint’ text inside the
label
- waaaay too pale when inside a link inside the label
This commit overrides elements to dim the disabled radio button by
making it’s text colour grey, rather than making the whole thing
semi-transparent.
The visual appearance of radio and checkbox form inputs changed in
GOV.UK Elements here:
https://github.com/alphagov/govuk_elements/pull/296
This was subsequently reimplemented with different markup and no
Javascript here:
https://github.com/alphagov/govuk_elements/pull/406
This has meant making the following changes to our app:
- changing the markup in our radio/checkbox macros to match the example
markup given by GOV.UK Elements
- removing the previous Javascript file because it’s no longer needed to
make the radios appear visual selected
- making the buttons on the scheduled job picker look like links,
because the grey button style looked weird with the new radio buttons
- SMS message preview gets slightly wider so it lines up with a 4/8
column
- Edit email box gets wider to match more closely the width of the
previewed and delivered emails
Not sure how these got out of line (maybe when we brought the date into
the left-hand text area). But this commit updates the percentages to
match the comments.
This is so it’s clear from the position of the link which part of the
letter you’re editing.
The textbox we use for editing letters is the same size as that for
email and text messages.
This is problematic because:
- it feels quite cramped – letters will often be longer than emails or
text messages
- it has a narrower line length than the printed letters (which is a
constant, unlike for emails and text messages)
The printed letters have a line length of 137.5mm and a font size of
12.5pt.
137.5mm = 5.41 inches = 389.7pt line length
389.7pt/12.5pt = 31.8em
So we could make the box 31.8em wide, but then it wouldn’t align to our
grid.
Our grid splits the page into quarters initially because this is how
wide the navigation is. So this means that we can use grid units of
1/multiples of four, eg 1/4, 1/8, 1/12, 1/16, etc. But the smaller the
denominator, the less effective the grid will be – it gets closer to no
grid at all.
After having a play around, 5/8 of the page looks closest to 31.8em.
Since the main column of the page is 3/4, we set a column of 5/6 width
inside that, which equals 5/8 of the total page.
We’ve seen in letters usability testing that people get stuck in a
“no-man’s land” when trying to go back from the _Send yourself a test_
page.
This was broken for two reasons:
- we hadn’t considered that a letter template without placeholder still
requires you to fill in
- we’ve changed subsequently made the _view template_ page the place
where you do your actions, rather than the (old) page with all the
templates shown
So this commit fixes it so that the back link always take you back to
the page you were previously on, and adds some more test cases so we
have all the scenarios accounted for.
The `format_datetime_relative` filter is only used by the scheduling
stuff, which only deals with dates in the future.
When used on dates in the past (more than 1 day ago) it gets confused
and defaults to ‘tomorrow’.
The `format_delta` method does a similar thing, but works for past and
future dates.
Users can still click through to the next page to see the exact date and
time of the edits.
Address line 3 is optional. Currently the only way we have of indicating
to users what is/isn’t optional is by using the example. Which probably
isn’t ideal, but should at least be correct.
The breaking change page wasn’t properly accounting for the fact that
letter recipients span multiple columns – it was assuming they’d only
take up one column like they do for email and SMS.
This commit fixes:
- the number of column headers (A, B, C, …) to be correct
- the count of columns (you will need X columns in your file) to be
correct
It then parameterises the test to look at a case where a recipient is
in one column (email) and multiple columns (letter).
Brings in:
- [ ] https://github.com/alphagov/notifications-utils/pull/128
This means that `RecipientCSV` will sometimes return the value of a cell
in a spreadsheet as a `list`, not a `string`. So we need to handle that,
rather than putting a Python representation (`['one', 'two', 'three']`)
on the page.
This commit handles it by putting a bulleted list on the page instead.
This breaks our model of showing the spreadsheet as it appears in Excel
or whatever, because we’re showing the aggregation of the columns into a
list. However:
- this is the easier thing to do for now
- it might actually be more usable because it keeps the table narrower
No need to repeat the same field-calling code each time.
Think we didn’t do this before because there was no way of passing the
`status` through to the `text_field` macro.
We set a URL for the app to use to access itself. On PaaS this is
configurable, locally we default to `localhost`. `localhost` doesn’t
(easily?) support HTTPS, so this default wasn’t working.
Users who go to edit the contact details for a letter from the template
page get very confused when they click save and are dumped on the
settings page. It doesn’t match the way editing other parts of
letter works, and you can’t see an accurate preview of the changes from
the settings page.
So this commit changes the flow to go from the _edit contact details_
page back to the _view template_ page when the user has got there by
clicking the blue _Edit_ button on the _view template_ page.
This page is not the place where you edit the contact details. Nor is
it the place where you can preview changes to the contact block. In
research users never found the link to get from this page to the edit
contact details page. So this commit removes it.
pass in the base URL - if not set in the environment this is set to
localhost, but on paas we can pull this out of vcap_services so that
letters render properly on paas
