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
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.
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.
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
Text messages have a maximum length, which we tell the users. We
shouldn’t expect people to count the characters in the message
themselves.
This commit borrows [the word counter from the Digital Marketplace
frontend toolkit](9d17690de5/toolkit/javascripts/word-counter.js)
and adapts it to count characters instead.
Things I’m still not sure about with this:
- what should it say when the message goes over the length of one text
message
- what’s the interaction with placeholders, which will change the length
of the message
This commit also adds a line to the pricing page which explains that
service name counts towards the length of the message.
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.
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.
Templates now have:
- a type (email or sms)
- a subject (if they are email templates)
We don’t want two completely separate view files for email and SMS, because they
would have an enormous amount of repetition.
So this commit adds
- different templates for SMS and email templates
- different form objects for SMS and email templates
…and wires them up.
