It’s a bit rudimentary to only show the current place in the hierarchy
and the parent. You lose a sense of how deep you are.
But we can’t just show the full path, because it can be arbitrarily
long. So what this commit does is show the full path, but truncates the
display of any items. Further-up than the current folder or its parent.
This also helps disambiguate between folders and templates, because
folders are always shown with the folder icon.
This probably won’t affect many teams, because we don’t anticipate a lot
of deep nesting.
It had too much whitespace because it was accidentally being given the
wrong class.
This commit undoes the change that caused it (which was while working on
letters) and beefs up our tests for email and text messages (so if this
happened again the tests would catch it).
Changed the table for displaying all notifications to show letters which
have the status of 'validation-failed' as 'Validation failed' instead of
'Cancelled'.
The individual notification page for a letter which has failed
validation has not been changed since this already has a description
(letter has content outside the printable area).
We already have a pattern for navigation folders and searching for
templates – let’s use it for the copy page too. And I reckon we can
represent services as folders if the user has multiple services they
could copy a template from.
Uses some CSS to draw some grey lines to show which radios descend from
which.
I don’t feel like the intentation is enough, and it looks a bit messy
because the circles of the radio buttons don’t have straight edges
easily suggest visual alignment.
Copies the design from conditionally revealing content in the design
system:
https://design-system.service.gov.uk/components/radios/#conditionally-revealing-content
Implementation is done with pseudo elements, because borders can’t be
positionned exactly enough.
Updated the move folder form to add a hint for the radio button for the
current folder saying 'current folder'. This hint does not get shown if
you are viewing all folders (so you are not inside a folder).
Also stopped a default radio button from being selected on the form.
After showing this to a few people the consensus seems to be that
‘Templates’ isn’t itself a folder. Therefore it shouldn’t have a folder
icon.
This has the advantage of disambiguating between being in a folder:
> [screenshot]
…and being in a subfolder:
> [screenshot]
In the long term, we don't want to show cancelled letters. But for now,
this changes cancelled letters to display in the same way that letters
with a status of permanent-failure, since we are currently giving
letters that we want to cancel the status of permanent failure.
the html now contains a `data-prev-state` attribute which contains the
previous state, taken from the `operation` value in the form data (from
the submit button). This is used to seed the `currentState` of the
templateFolderForm. If not specified (or 'unknown', because the user
hit enter last time round), then set it to nothingSelectedButtons.
The Jinja template for the ‘choose templates’ page is now pulling in
data from a lot of diparate places in order to work out what to show. As
we add more logic about what to show (in order to make the live search
work) it’s going to get harder to have all this logic in the Jinja
template.
This commit refactors it back into Python where we have more language
features for managing complex logic.
It’s a bit weird to call this file a model, in that it’s dealing with
some presentational logic, rather than just data. Conceptually it’s more
like a view model[1].
1. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
This makes the display of folders in the `<h1>` look like the prototype.
It alters the behaviour we’ve initially built here by only ever showing
a maximum of two levels of hierarchy (the current folders and its
parent).
It feels like a solid reckon that knowing what’s in a folder before you
click on it will help you navigate around.
However, what do you show in a folder if you’re filtering by template
type? We think that:
- if you’re not filtering you should see all folders, even empty ones
- if you’re filtering you should only see folders that will get you to
relevant templates
This matches what happens when you filter templates, we don’t ‘grey out’
the non-email templates, we hide them completely.
The logic then extends to how we describe the contents of a folder, ie
we won’t count its subfolders if they don’t contain templates of the
type we’re looking for. This means that however you see the folder
described (eg ‘3 templates, 1 folder’) will match what you see when you
click into it.
This commit adds logic to:
- take the list of selected folders and templates
- split it into two lists (of folders and templates)
- `POST` that data to the API, to effect the movement of said folders
and templates
I’ve tried to architect it in such a way that we can easily add more
template ‘operations’ in the future, as we add more forms to the choose
template page.
This commit adds:
- checkboxes to let you select a template or folder
- radio buttons to let you select where to move those template(s) and/or
folder(s) to
It only does the `get` part of this work; handling the `post` and
calling API will be done in a subsequent commit.
At the moment we show precompiled letters that have failed the
validation as having been sent. This is confusing.
We should communicate it as having been cancelled (rather than failed),
with the implication being that Notify has come along and cancelled the
letter before printing it. I think this is conceptually what makes the
most sense.
From the user’s point of view any letters that show up as cancelled
probably need to be fixed and resent, so it makes sense to group them
with the same name.
At the moment we are manually cancelling letters for people when they
ask us to. Once’s we’ve done this there is no indication that it’s
happened except for the date going red on the list of letters.
This commit adds some error messaging and styling to show when a letter
is cancelled.
Letting people cancel their own letters will be a future enhancement.
For reasons I don’t understand some of our text messages get marked as `pending`. Since we don’t account for this in the front end they don’t get displayed quite right (the vertical position of the text is too high). This commit adds the pending `state` to the `if` statement so the text is properly aligned.
- add get/post view
- create a pdf upload form
- add a template where user can upload the file
- check boundaries of the letter by calling template-preview
- display banner messages with boundaries validation result
- display pages of the document, with visible boundaries overlay
if the document did not pass validation, and without overlay
if they do pass validation
This duplicates how the task list pattern is coded in the GOV.UK
Prototype kit[1]. It adds ARIA attributes and the use of a
semantically-meaningful element (`<strong>`) to give more information to
screen reader users.
1. https://govuk-prototype-kit.herokuapp.com/docs/templates/task-list
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
Since GDPR came into effect it’s less clear about whether we can
contact teams for user research purposes.
If we make people opt-in (or not) we know we’re safe to contact them (or
not).
Since we mostly care about how services are using Notify for real (ie
live services) or services that are considering adopting it (ie those
who have contacted us with a question) it feels like the go-live process
is the most appropriate place to collect this consent.
We’ve found a significant property of users (about 25%) who request to
go live aren’t completing all the items on the checklist.
In 1 of 6 (17%) of the usability testing sessions we did on this process
we saw someone skip straight past the checklist page because of big
green button syndrome. While 1 in 6 people would normally be a small
number[1] in the context of a usability testing session, it’s enough to
cause a big workload for our team (assuming it is the sole cause of
people not completing the items on the checklist).
The initial reason for using the tick cross pattern for the checklist
was:
- it was coherent with the rest of Notify
- the task list pattern didn’t have a way of showing that something
still needed doing – it put more visual emphasis on the things
the user had already done
There’s been some interesting discussion on the GOV.UK Design System
backlog about users failing to complete items in the task list. A few
people have tried different patterns for communicating that items in the
task list still need ‘completing’.
So this commit:
- adds a task list pattern
- uses the task list pattern for the request to go live checklist
The task list is adapted from the one in the design system in that:
- the ‘completed’ label has a black, not blue background (because Notify
often uses blocks of blue to indicate something that’s clickable)
- it adds an explicit ‘not complete’ label which is visually not
filled in (sort of how ticked/unticket radio buttons work)
1. With the caveat that looking only at task completion, or quantifying
qualitative not good practices and the intention here is to show that
the numbers are close enough to say that they could be symptomatic of
the same problem. Leisa Reichelt’s Mind the Product talk is good on
this https://vimeo.com/284015765
This commit improves the code that previews a hex colour when setting up
or changing an email branding.
Specifically it:
- refactors the Javascript to conform to our patterns (module pattern,
preprocessed with Gulp)
- makes the code work when there are multiple colour previews on one
page
It also does some visual prettifying, because I couldn’t help myself…
Service contact details are needed if the upload document permission is
enabled - this used to be a link but services can now choose to use a
link, email address or phone number. The form to add or change service
contact details now gives these options and validates the data according
to the type of contact details provided.
When validating phone numbers we can't use the existing validation
because we want to allow landlines too, so there is a basic check that
the phone number is the right length and doesn't include certain
characters.
‘Upload recipients’ and ‘Send to one recipient’ have always been
slightly clunky phrases.
Now that basic view jumps straight into the ‘Send to one recipient’
flow there’s no way for users to get to the ‘Upload recipients’ flow.
By adding a link to it from the ‘Send to one recipient’ flow it’s
possible for users of basic view to access it.
But we don’t want to introduce too much inconsistency between basic view
and admin view because users will be migrating from one to another. They
might also be talking to their manager, who wouldn’t be able to tell
them where to click if they were looking at two completely different
interfaces.
This also means that we can keep the left-hand navigation in basic view
nice and simple with the two options (‘Templates’ and ‘Sent messages’),
rather than trying to introduce something like ‘Send one message’ and
‘Send lots of messages’ later on.
Often we show/hide these rows based on what permissions a service has.
This commits refactors that check into a reusable macro, rather than
having to write the same `if` statements all the time.
In research we found that:
- people didn’t initially realise that the permissions expanded when the
‘admin’ option was selected
- not having all the options visible at once makes it hard to know what
permissions you are (and more importantly aren’t) giving to people
This commit makes it so that:
- the options within the ‘admin’ option are always visible
- a bit of Javascript logic makes it so you can pick ‘caseworker’ and
‘manage service’, for example (by deselecting one when you pick the
other)
This commit changes the form that the user sees when inviting or editing
another user, if the service has the ‘caseworking’ permission set.
This will allow creating a new type of user, one who only has the
`send_messages` permission, without the `view_activity` permission.
We are doing this because we think there are a number of services with a
lot of users who don’t need to see the dashboard, or the other team
members, and that we can make a simpler interface for these users.
This commit splits up the radio buttons macro into a couple of different
macros which can be used independently of each other.
This makes this code easier to reuse when implementing custom radio
controls.
