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.
Added a new platform admin page, at '/plaform-admin-new' which shows
different data. This no longer offers the option to filter by test-key,
only by date, and also gives a more detailed break-down of the
notifications and failures sent with a normal / research key.
The existing platform admin stats page ('/platform-admin') has not been
deleted yet so that both pages can be compared.
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.
At the moment branding is an undocumented feature. We get a bunch of
support tickets from teams asking its possible.
This commit:
- lets people know it’s possible, and what the options are
- is the first step towards making this process as self-service as
possible
In some cases we will be able to infer a user’s organisation from there
email address, and Google image search their logo. So the experience for
them is that they press a button and government just sorts it out for
you (also known as "the dream").
In other cases we will have to get back to people asking for a copy of
their logo, or to find out about their service, but this is what we have
to do at the moment anyway.
Because we now[1] store info about each file upload separately in the
session the session isn’t overridden every time you upload a file. This
is good because you can do multiple file uploads idempotently.
Generally we are cleaning up after ourselves because we pop anything to
do with that upload from the session. However there is an edge case: if
you never send the file then the info about the file stays in the
session in perpetuity[2]. This is generally happening when people are
uploading files that are impossible to send, ie ones that have errors.
So this commit makes two changes:
1. remove info about a file upload from the session as soon as we know
that it contains errors
2. `POST` reuploads to the same endpoint as initial uploads because
otherwise we need to keep info about bad uploads in the session,
which would prevent us from doing 1.
1. https://github.com/alphagov/notifications-admin/pull/1968
2. or at least until the session is cleared by the user logging out
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.
The email template does this already when formatting the body of the
message. But the spreadsheet preview doesn’t, which means you get lists
like:
- thing
- thing
- None
This commit fixes that.
This was a pre-existing bug, but gonna roll it in with this PR.
For text messages/emails it makes sense for ‘sending’ to be gray and
‘delivered’ to be black. But since we don’t show sending/delivered for
letters it doesn’t make sense for the text to change colour.
we branch on any_ to either say "require ALL these permissions" or
"require ANY of these permissions". But we only ever call the decorator
with one permission, or with any_=True, so it's unnecessary
One of the things that we want to check before a service goes live is
that they have at least two team members with the manage service
permission. Anyone who can make a request to go live has this
permission, so that means one additional user is needed. This is what we
can automatically communicate to the user.
Under the hood this makes use of the logic added in
https://github.com/alphagov/notifications-admin/pull/1891
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
We started tracking upload errors in eb264f34b7
This has been useful.
This commit adds tracking of other form validation errors, so we can
pick up if there’s a form field that’s causing people particular
trouble.
Also had to rewrite a very old test to look for page content in a
smarter way.
The first users of multiple email reply to addresses will be using the
API. This means that the need to be able to specify the ID of the reply
to address they want.
We chose to implement it like this instead of by passing the address in
directly because that means deploying code. For some teams deploying
code can take weeks, and we’d like to let teams have the flexibility to
make changes faster than this.
Same as for templates, you shouldn’t have to go to the _edit_ page in
order to get the ID. This means listing them on the page where you see
all the reply to addresses.
Listing the IDs like this means that it’s not really a table any more,
because the information isn’t organised in columns. So I think it makes
sense to reuse the pattern from the manage team page, which has a
similar relationship between the information.
It’s not either text messages, or emails, or both now – it’s any
combination of the three channels.
This commit adds ‘letters’ as an option on the request to go live page
by changing the radio buttons to a group of checkboxes, so the user can
choose as many or as few as they want.
This commit also does a bunch of housekeeping stuff around the tests for
this page, because they haven’t been touched in quite some time.
