- 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
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.
All services have the `upload_document` permission now, so we don't need
to check for it on the email formatting page. This also deletes a test
which is not needed now.
This adds spacing classes from the design system where necessary to keep
the spacing looking the same.
It also replaces the `<aside>` elements with a `<div>` on the edit
template pages. The accessibility audit noted that these were inside a
`<main>` element, so screen readers may not be able to navigate the
elements correctly.
Proof of concept for the GovukRadiosField class.
Includes the removal of the a DataRequired
validator. This doesn't seem to be needed as the
RadioField superclass catches any submissions
without any data from field.choices in its
pre_validate method (which also outputs the
correct error message).
Updates StringField to GovukTextInputField.
These changes also affect the following forms that
inherit from BaseTemplateForm:
- SMSTemplateForm
- EmailTemplateForm
Includes changes to templates that use these forms
and associated tests.
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`
HighlightTags was bad because:
- we haven’t called placeholders ‘tags’ for a long time
- it also does resizing of the `<textarea>`, not just highlighting the
placeholders
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.
If you have a long template it’s annoying to have to scroll all the
way to the bottom to click save, when you’ve only changed a small thing
near the staert of the content.
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
Document download is in private beta, which means most teams using
Notify can’t see or use it.
We shouldn’t confuse people by showing them this guidance, especially
while it’s API-only.
Sometimes when setting up a service you might have a few very similar
templates, in which only a small amount of content. Or you might even
have a few of services, which are used by different teams but have
similar templates.
Copy and pasting, especially from one service to another, is a pain.
This commit makes it easier by allowing users to copy an existing
template when choosing to add a new one, instead of starting from
scratch.
platform_admin is a separate concept to permissions, so by removing the
checks for it from the current_user.has_permissions function, we can
simplify things greatly. We already record on the user whether they're
a platform admin anyway.
Users were having trouble finding the delete template link. It sort of
made sense having it on the edit page before we had the view template
page. But it doesn’t make sense now – having to choose to ‘edit’ the
template before you can delete is counterintuitive.
The single template page is where you go to choose an action to perform
on your template. Deleting is a good example of an action you can
perform on a template.
So this commit moves the delete link from the edit template page to the
view template page.
It also puts the confirm banner on same page as the delete link
The idea being that, in order to make a decision about whether to delete
the template, it’s useful to be able to see the template you’re
deleting. There’s no user need to edit the template before you delete
it.
- 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
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.
There is a check that the template can not be created as priority if the user is not a platform admin.
There is a check that the template can not change the `priority` unless they are a platform admin.
This is based on some work Gwen did for Civil Service Digital. Let’s
get it in for now so that we have a starting point from which to
improve.
This specifically doesn’t reference ‘optional’ placeholders because I
don’t know how best to explain those yet.
Two problems with having it on the side:
- some users didn’t see it at all
- there wasn’t space to have additional guidance about Markdown-style
formatting
There are some common questions that keep coming up when users are
editing or creating templates. This commit adds a pattern for sections
of guidance which can be shown/hidden.
It then modifies the guidance as follows.
Change:
- guidance about placeholders; give an example about what to do and what
not to do (because the mistake we keep seeing people make is putting
the thing itself, not the name of the thing)
Add (pretty basic at the moment but a need for these has come out of
research):
- guidance about links
- guidance about message length for text messages
_The code for this is quite hacky and light on tests. But I’d really like to get
it in the app for the research tomorrow to see how well the feature works._
This commit changes the tour from being a set of static screens to some help
which guides you through the process of sending your first test message.
The theory behind this is that what users are really struggling with is the
concept of a variable, rather than the relationship between the placeholders and
the column headers. And like learning to program, the best way to learn is by
taking an example and modifying it to your own needs.
This means that when someone adds their first service we set them up an
example email template and an example text message template. Then there is a
guided, three step process where _all_ the user can do is send a test message to
themselves.
Once the message is sent, the user still has the example templates which they
can edit, rather than having to remember what they’re supposed to be doing.
If the hint aligns with the message body then it looks like you can only
add placeholders to the body. This commit aligns it with the subject
instead, and since it overlaps both it looks like you can add
placeholders to both (hopefully).
This commit makes the placeholder hint not be dependent on their only
being one textbox with placeholders on a page.
To do this it needs to be its own module, because the two textboxes are
each self-contained instances of the same module.
The way I’ve gone about this is to make the placeholder hint accept a
list of textboxes it should look in when deciding what message to
display to the user.
Most of the code is extracted from the existing placeholder highlighting
module.
In order for subject lines to have their fields highlighted they have to
be textboxes. This is because the highlighting script only works with
textboxes that don’t scroll, either horizontally, vertically, or be
keying through them.
We’ve seen lots of users unsure what the ‘template name’ field is for,
especially on first use. Is it the subject line of the text message?
Will it be who the message comes from? Answer: neither.
So this commit adds a hint to make that clearer.
This commit makes the ‘how to do placeholders’ box part of the tour,
with the same blue background.
It also adds some Javascript enhancement so that:
- it responds to the contents of the message template
- has a ‘show me’ link which inserts ‘Dear ((name))’ into the template
contents textbox
We’ve found that this has helped people understnad what placeholders
are, and how to do them.
The same `.html` file is shared between adding a template and editing a
template.
The page heading needs to be contextual to the URL, either ‘add’ or ‘edit’.
Somewhere along the way this got lost; this commit reinstates it.
In research we’ve seen users struggle with this. Often they’d type
((Joe Bloggs)) or ((XX/XX/XXXX)) instead of a sensible name.
Lets see if explaining it differently helps.
