Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
Includes:
- turning off :visited styles to match existing
design
- swapping heading classes used to make links bold
for the GOVUK Frontend bold override class
- adding visually hidden text to some links to
make them work when isolated from their context
We may need to revisit whether some links, such as
those for documentation and features, may benefit
from having some indication that their target has
been visited.
The Design System has standardised on back links being at the top of the
page, decorated with a small text-coloured arrow.
I think this makes more sense than having them at the bottom, because it
suggests, in some way, being able to go back before commiting to any of
the forms on the page. Whereas the things at the bottom of the page
should be performing actions on what’s in the page.
The reason for making this change now is that it de-clutters the area
around the green buttons. This was presenting a design challenge where
multiple levels of interaction were happening in the same form. Moving
these back links to the top of the page should mean that, in these
complicated forms, there’s one fewer thing to compete for the user’s
attention.
I’ve componentised this into a `page_header` macro so that the change is
easier to roll out and maintain.
This replicates how we let large spreadsheets scroll horizontally.
Pro: this looks nicer and is more usable
Con: the code for this feels a bit fragile, especially the calling of
`.maintainWidth` twice, ie as many times as a it takes to get stuff to
render properly.
We should standardise on <a download> rather than
<a download="download"> everywhere. The value of the download attribute
tells the browser what filename to use, but is overridden by the
Content-Disposition HTTP header. Since it’s not being used, we should
remove it for the sake of disambiguation.
We wouldn’t wan’t anyone just seeing the raw CSV data in their browser – it isn’t clear what a user would do with it at that point. And we wouldn’t want it navigating them away from the send page, because this might cause them to lose their place.
This commit forces the file to download using the HTML5 `download` attribute:
> This attribute instructs browsers to download a URL instead of navigating to it, so the user will be prompted to save it as a local file.
– https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download
Having to scroll past the template preview is fine for a short text
message, but annoying and confusing for a long letter. We even have
people completely missing what the page is for, because they don’t go
all the way to the bottom.
This change makes more sense now that we have a page for previewing a
template (not one long page with all the templates). You’re already
pretty confident that you’re using the right template on this page. It’s
just there as a double-check, and to help people understand where the
columns in the example file are coming from.
It doesn’t need to be a bullet point for each format. We tested this in
research with DWP staff yesterday and it didn’t cause any problems. I
also think it’s nicer for the UI to tell you what you need to do, rather
than tell you what it can “accept”.
In pages specific to a service (e.g. dashboard and sub pages) the title
needs to distinguish which service it applies to. This is mainly to give
context to screen reader users who could be managing multiple services.
Implementing this uses template inheritance:
`page_title` includes `per_page_title` includes `service_page_title`
‘GOV.UK Notify’ is inserted into every page title.
Pages that set `service_page_title` get the service name inserted too.
Let users create/edit/delete letter templates.
Let them upload a CSV file or send a test against a letter template.
Big assumption at the moment is that addresses only have one line, and
therefore one column in the CSV file.
People missed this example because it was hidden in a `<details>`
element. Perhaps the wording of the link wasn’t ideal, but we’ve
tried two different varations of it (https://github.com/alphagov/notifications-admin/pull/640)
Better not to hide things, than try to think of some text which will
make people want to show them.
Also adds some headings to chunk up this page a bit.
…and change the page heading on next page to match.
‘Send emails’ doesn’t speak to you if you already have the idea of a
file or address book in mind. ‘Upload’ better describes what you’re
going to do on the next page.
Also makes all the links regular weight, because having the first one
bold looked like a heading.
This changes it back to how it was when we first introduced this
feature:
https://github.com/alphagov/notifications-admin/pull/181
It’s kind of lost on the page where you upload a file, which is a shame
because it’s a good teaching aid.
‘How to format your file’ sounds complicated and incidental.
‘See an example’ sounds like something that might be useful if you’re feeling
stuck.
Also makes the list of file formats a list, because it’s a list.
Now that the example on the breaking changes page looks more like a spreadsheet,
we should do the same thing for the downloadable example on the send page.
The details element is fairly new. It doesn’t work in all browsers,
and isn’t keyboard/screenreader accessible even in some new browsers.
This commit adds the Polyfill script from GOV.UK elements[1] which
polyfills these features for browsers that don’t support them.
1. http://govuk-elements.herokuapp.com/typography/#typography-hidden-text
> On the send pages, we have a call to action in the middle of the
> page with lots of words and placeholder buttony looking things
> above and below it....
>
> You'll also see this every time you use this page, even though you
> probably get it after a single use.
>
> So let's wrap it up under a usefully titled (?) help link that
> expands to reveal all the things.
This commit implements the above.
It also rewords the messaging to talk about various spreadsheet formats,
not just CSV.
This commit does two main things:
- adds textboxes to the send yourself a test page, so you can replace
((name)) with ‘Chris’, or whatever your name is
- rejigs the send page a bit to make it clearer what the CSV upload is
for and how to use it
The idea being that, since most users go into ‘send yourself a test’
first, it teaches them about how placeholders work by making them do the
replacing themselves.
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
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.
On:
- the API keys page
- the ‘send’ page
There are some inconsistently small heading sizes. This commit makes them
consistent with the heading sizes on other pages.
On the send page, it should hightlight the placeholders so they match
what you need to put in the CSV file.
On the check page, they should not be highlighted, to match what’s in
the (rendered) template.
When a table is showing the contents of a CSV file, it should look
something like a spreadsheet.
The minimally skeuomorphic way to do this is by adding row numbers.
This commit doesn’t
- make the row numbers monospace (it’s barely noticeable and doesn’t
reflect what actual spreadsheets do)
- make the first column heading ‘Row’ (again, doesn’t reflect how actual
spreadsheets work, and takes up more valuable space)
Would like to test something like this and see how well it works.
Intention of having this page is so:
- template IDs are discoverable (https://www.pivotaltracker.com/story/show/115404593)
- it’s obvious there’s an ‘automated’ way to send messages, as well as the CSV
way (we’ve seen people oblivious to this in research)
CSV files currently have ‘to’ as the recipient column. This is changing in
https://github.com/alphagov/notifications-api/pull/109
The admin app also has to validate that the CSV files have the right columns,
because the API expects any CSV that it’s given to have been checked (also we
want things to actually work).
This commit is the minimum code change needed. In the future it should reuse
the same code as the API for processing CSV files. This will need more thinking.
This commit adds some guidance on the ‘Add recipients’ page about what should
be in the CSV file. The guidance is contextual to the template, and based on
the problems that we saw users having yesterday.
Use one page template for each of:
- choosing a message template
- adding recipients
- checking an email message
- looking at a job
This commit consolidates the two templates into one, and adds logic to show
the SMS message pattern or the email message pattern depending on the type of
template.
It also gives email templates a bit more width, because the body and the from
address tend to be quite long.
This commit parameterises all methods in the send view so that they can send
either emails or SMS messages.
It works out what kind of message it is sending from the `template_type`
property of the template object.
This means that the `Template` util class needs to know about these properties,
which means that this commit depends on:
https://github.com/alphagov/notifications-utils/pull/2
This commit does _not_ add tests for sending emails. The existing tests for
sending SMS still pass, but actually sending emails is outside the scope of
this story.
