- Deleted /stylesheets folder
- Removed sass build from gulpfile
- Changed gov links to usa links
- Changed other govuk styles, like breadcrumbs
- Changed name of uk_components file to us_components
- Fixed a few tests that broke on account of the changes
* Updated header and footer
* Moved files around and updated gulpfile to correct the build process when it goes to production
* Updated fonts
* Adjusted grid templating
* Adding images to assets
* Updated account pages, dashboard, and pages in message sending flow
* Updated the styling for the landing pages in the account section once logged in
* Updated header and footer
* Updated fonts
* Moved files around and updated gulpfile to correct the build process when it goes to production
* Adjusted grid templating
* Added images to assets
* Update app/templates/components/uk_components/footer/template.njk
Co-authored-by: Steven Reilly <stvnrlly@users.noreply.github.com>
This has several advantages:
- It gives us more room to explain the error and actions. This will
be useful for upcoming work we want to do, which will add yet more
validations for CSV uploads.
- We already use a flash to show certain kinds of errors on these
pages (just above). This is more consistent.
- It's potentially more accessible. Previously the error and the
button text used to be read out as a single sentence. Now the page
reloads and reads the flash error alone.
In theory we should show an error in both places, but this can be
confusing on pages where there's only a single form control, and
especially if the error is long.
The page_header macro includes an optional back link. Since the
page_header is always used inside `<main>`, where the back link should
not be, this stops setting the back link in the page header and instead
sets it in the new `backLink` block.
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.
