When we converted textboxes on Notify to govuk-frontend design system
style with @tombye , we did not remove the imports.
This work is now done in this commit.
Some things that will still stay in our repo for now:
textbox macro in our components folder and associated css
textboxes which are really textarea fields (🤷 how do they work)
textboxes on the styleguide page
We should revisit this when we convert textarea fields
to govuk-frontend.
Includes the following pages:
- letter contact (in service settings)
- sms-senders page (in service settings)
- email reply-to (in service settings)
- API key page
Note: the call on the letter contact page uses
the first line of the contact address as the
unique identifier for each button.
We had two identical callback form classes. One for delivery callbacks
and one for inbound sms callbacks. Since they did not differ I consolidated
them into one CallbackForm class that they both inherited from previously.
I also substituted field classes for this form with new fields
that cooperate with gov uk frontend.
This commit changes all the places where a user would see the term
‘whitelist’ in the content of page to say guestlist instead.
We’re removing the term ‘whitelist’ for two reasons. The first reason
is that we agree with the National Cyber Security Centre say:
> It's fairly common to say whitelisting and blacklisting to describe
> desirable and undesirable things in cyber security. For instance, when
> talking about which applications you will allow or deny on your
> corporate network; or deciding which bad passwords you want your users
> not to be able to use.
> However, there's an issue with the terminology. It only makes sense if
> you equate white with 'good, permitted, safe' and black with 'bad,
> dangerous, forbidden'. There are some obvious problems with this. So
> in the name of helping to stamp out racism in cyber security, we will
> avoid this casually pejorative wording on our website in the future.
> No, it's not the biggest issue in the world - but to borrow a slogan
> from elsewhere: every little helps.
– https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white
The second reason is that we’ve observed some users think that they have
to put recipients in the whitelist even when they’re already with in the
team. We think that the term ‘whitelist’ might be reinforcing this
mental model because of how ‘whitelists’ might work in other
applications.
We considered the following alternatives or concepts:
- Development
- Recipients
- Sandbox
- Extended team
- Smoke test recipients
- Allowed
- Nominated
- Bonus
- Additional
- Safe
- Team list
- Trusted contacts
- Designated people
- Guest list
- Team key list
We also considered not giving it a name, and explaining it as a nuance
of how the team key works. After mocking this up it felt more disjoined.
We think it’s still useful for the thing to have a name so that it’s
easy to refer to between the docs and the UI.
We like the term ‘guest list’ because:
- of how it sits with team members – members and guests in the abstract
- a guest list is a concept that a lot of people will be familiar with
– a list of people who can access a thing
- ‘guest’ is very different to ‘recipient’ – we want to mitigate any
confusion between this and the (emergency) contact lists
All paragraphs should have class="govuk-body", or be otherwise
custom-styled. This commit adds some extra checks to our test fixture
that looks for paragraphs that don’t have any styling. Our test coverage
is pretty good, so this should check almost all pages, and prevent
regressions.
I’ve done this in such a way that it can be extended for other elements
(e.g. links) in the future.
We had 7 classes in _grids.scss named `.column-...` which were being
used to give a certain column width. These worked by using `@include
grid column()`, which is now deprecated.
`.column-whole` and `.column-three-quarters` can be removed and replaced
with `govuk-grid-column-full` and `govuk-grid-column-three-quarters`
respectively. The other column classes don't have a direct replacment in
GOV.UK Frontend. To get round this, we overwrite the `$govuk-grid-width`
SASS map in `extensions.scss` to add in extra widths, then use this with
the `govuk-grid-column` mixin to create new classes in for our custom
widths in `_grids.scss`
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
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.
Converts links in the following:
- the page-footer component
- the table component
- the browse-list component
- the notification status, when reporting failures
- validation messaging in the whitelist page
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.
This replaces the buttons that aren't part of a macro and that we don't
need to write additional styles for with their govuk-frontend equivalent.
There were some links that were styled to look like buttons, so these
have also been replaced with the new govuk-frontend macro.
There was one button on the `choose-account.html` template that was in a
section of code that was never reached - this has been deleted.
The GOV.UK Frontend details component macro
wraps its `<summary>` text in a `<span>`.
We put a `<h3>` in the `<summary>` (actually valid
use, based on the spec) so this breaks when the
`<span>` wraps it.
This converts the existing `<details>` tag to use
all the class names the macro creates, but with
all the `<summary>` contents in the `<h3>`.
Also adds font-smoothing to the messages on the
API page. This was previously set globally for
all fonts in the GOV.UK Template CSS but is now
just set for the New Transport 'nta' font.
Included because the messages use the monospace
font so don't have it by default.
The GOV.UK Frontend details component macro
wraps its `<summary>` text in a `<span>`.
We put a `<h3>` in the `<summary>` (actually valid
use, based on the spec) so this breaks when the
`<span>` wraps it.
This converts the existing `<details>` tag to use
all the class names the macro creates, but with
all the `<summary>` contents in the `<h3>`.
Also adds font-smoothing to the messages on the
API page. This was previously set globally for
all fonts in the GOV.UK Template CSS but is now
just set for the New Transport 'nta' font.
Included because the messages use the monospace
font so don't have it by default.
Since we added template folders the templates page has had a ‘medium’
sized heading, where other pages have stuck with a ‘large’ size.
This commit rationalises the decision around which pages have which
heading size:
- ‘navigation’ pages (eg templates, team members, email reply to
addresses) have medium sized headings
- transactional pages (ie ones which have a green button) keep the
larger heading size
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.
Counting pages for API notifications takes a long time for services
with a lot of sent messages (since it issues a `count(*)` query for
the given filter). Since API message log doesn't have a "Next page"
link we can skip the count by setting a flag on the API request.
There was an awkward line break in this text, and the line length was
too long because there was no grid on the page.
Splitting it into two paragraphs makes it:
- read nicer
- avoids any awkward line breaks
Once all our users have upgraded to the latest clients they won’t need
this. The latest clients only use the combined key and service ID.
Discuss: when can we safely remove it?
This will stop us repeatedly forgetting to add `novalidate` and
`autocomplete='off'` to our forms (which is how most of them are set
up).
It uses sensible defaults, based on how we most-commonly configure
forms:
- most of our forms are `post`ed (but this can be overridden)
- `autocomplete` should only be enabled where it makes sense, otherwise
it’s more annoying than useful (but this can be overriden)
- we should never be using HTML5 form validation because our own error
styles and messages are better
It’s useful to be able to see what the email or text message looks like,
especially if you’ve sent it with a test API key (so it isn’t in your
inbox or on your phone). We already have the page for this, so we just
need to link to it.
The contact link on the settings page should be truncated instead of the
text being wrapped and overflowing on to multiple lines. This adds in an
option to the text_field macro to truncate long text fields. This
setting has been used to truncate the API callback URLs too on the
services/<service_id>/api/callbacks page.
Precompiled letters can now have two additional states:
* pending-virus-check
* virus-scan-failed
Both new states should show in the notifications dashboard, and
virus-scan-failed should appear as an error state, with a descriptive
message. You should not be able to preview a letter in one of the two
new states, so the preview link has been removed for precompiled letters
in these states.
Both `<button type='submit'>Submit<button>` and
`<input type='submit' value='Submit'>` can be used to submit a form.
We have historically[1] used `<input>` because it’s better-supported by
IE6 in that:
- the `submit` attribute is mandatory on `<button>`, not on `<input>`
- the `innerHTML` of a button will be submitted to the server, not the
value (as in other browsers)
Reasons to now use `<button>` instead:
- IE6/7 support is no longer a concern (especially with deprecation of
TLS 1.0 on the way)
- Because an `<input>` element can’t have children, the pseudo-element
hack[2] used to ensure the top edge of the button is clickable doesn’t
work. We’re seeing this bug[3] affect real users in research.
1. We inhereted our buttons from Digital Marketplace, here is me making
that change in their code: 8df7e2e79e (diff-b1420f7b7a25657d849edf90a70ef541)
2. 24e1906c0d (diff-ef0e4eb6f1e90b44b0c3fe39dce274a4R79)
3. https://github.com/alphagov/govuk_elements/issues/545
Delivery comes before inbound. The order of the URLs was jumbled in two
places:
- in the view function
- in the Jinja template
So as the user saw it the URLs were in the right order, because the
double jumbling cancelled itself out. But it made the code _really_
confusing to read.
