Problems:
- WTForms expects the value of checkboxes to always be `y` (they don’t
work like radio buttons, which is where I copied this code for)
- WTForms `BooleanField`s don’t have a checked attribute, they set their
data attibute to `True` or `False`
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).
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
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.
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.
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.
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.
When you’ve sent message(s) using a template, often the next thing you
want to do is go and send the same template again, or edit it.
Currently there’s no way of getting to a template from a job except for
going back to the list of templates and re-finding it.
This commit adds a link at the bottom of the job page that gives you a
shortcut back to the individual template, where you can find actions
like edit/send/etc.
Removed as part of refactoring the code to generate the graphs of
template usage on the dashboard:
4a226a7a29 (diff-cf78cb5c29a2d3c4d45b61d8617824b7L29)
Didn’t realise that they were used by the functional tests.
This commit puts them back while keeping the code reuse.
Making the navigation narrower means that we have more space on every
page. So on pages where we had to use 16px type just to fit stuff on the
page we can now bump the type size up to something less miserly. This is
mainly the team and settings pages.
We still need to use 16px on pages which list notifications or previews
of spreadsheets, because we’re still trying to fit a lot of information
onto these pages, so every little space-saving helps.
Like the template ID this is an infrequently-used action on a template
and doesn’t belong at the same level as ‘Upload recipients’ or
‘Send yourself’ a test. We don’t think it’s information that’s useful to
working out which template you want to interact with, so it shouldn’t be
on the choose template page any more.
Not necessary to have it on its own page – it’s one line of stuff. And
definitely not as frequent use as the ‘Upload recipients’ or ‘Send
yourself a test’ links.
Since we’ve simplified the left hand nav so much it doesn’t need 1/3 of
the width of the page. By making it smaller we have more space to show
previews of email and letter templates.
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.
