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.
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
The `oninput` event is a more performant way to detect changes to a
textbox’s contents (compared to `onkeydown`, `onpaste`, etc).
It’s not supported in older browsers, but since this is a likely to be
used by platform admin users only that’s OK.
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.
We’re interested to know which services are looking at the basic view
preview (even if they’re not turning it on).
This commit logs their service IDs as events into Google Analytics.
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.
One of the big things we found in user research was that people were
uncertain what the effect of giving someone basic view was.
So in the spirit of ‘show don’t tell’, this commit adds a way for users
to preview basic view. They can go into the preview and click around as
much as they like, just as if they really had the basic view assigned to
them.
Once they have seen enough they can return to the settings page where
they can decide whether or not to switch basic view on for real.
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.
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.
In research I’ve sometimes seen people click the wrong nav item. I
reckon that people’s concept of which pages live behind which navigation
items isn’t very strong.
We can reinforce this relationship by showing, for every page, which is
the corresponding nav item. The conventional way of doing this is either
with some kind of emphasis, typically colour or bold. I’ve gone for bold
because colour would be weird.
---
The implementation of this is quite loosely coupled to our application
code because:
- our application code is not well structured (eg we don’t make any use
of blueprints)
- spreading this change across lots of files in our application would
make it harder to test without actually hitting each endpoints; such
tests would be slow and verbose
So I’ve gone for more of a meta approach. Rather than testing that each
endpoint has a specific navigation item selected, I’ve gone for
validating that:
- all endpoints being mapped to are real
- all endpoints have _a_ selected navigation item (or are specifically
excluded)
This means that it’s impossible to add, change or remove an endpoint
without also updating which navigation item should be selected. And the
actual mapping is so declarative that it testing it would be redundant.
We have teams who are using the dashboard every day, and being
confronted with this alarming yellow banner. There’s no action they need
to do since they’re only looking at the messages sent.
So this commit removes that banner from the dashboard. It also removes
the CSS and HTML for it from the app entirely because this is the last
remaining place we were using this style of banner.
If someone has no permissions but needs permissions the thing they’re
probably going to need is to send a message or edit a template.
The place they will probably come to is the place where the buttons
would be – users with these permissions are finding the thing they need
to do on this page.
So this commit adds a line to this page which (hopefully) makes it clear
they’re in the right place, but need to go and speak to someone.
* Moved the notifications code to go to admin to get the the template
preview document rather than go to template preview.
This will remove the logic from admin and place it in api so it is
easier to expand on later when there are precompiled PDFs
* Added some error handling if API returns an API error.
Caught the error and displayed an error PNG so it is obvious something
failed. Currently it displayed a thumbnail of a png over the top of the
loading page, and therefore it wasn't obvious of the state.
Things in CSS stack top to bottom like this:
- image
- `box-shadow`
- `background`
We are drawing the border around the letter using `box-shadow`. This was
working fine because the images of our letters had a transparent
background, so you could see the border through them.
At some point our letters have changed to have a white background. So
you can no longer see the border.
This commit:
- adds a new pseudo element which stacks above the image of the letter
- moves the border from the image itself to said pseudo element
Caught the error and displayed an error PNG so it is obvious something
failed. Currently it displayed a thumbnail of a png over the top of the
loading page, and therefore it wasn't obvious of the state.
We have found repeatedly in research that our users don’t know what
‘beta’ means. In this situation they come up with their own
interpretation of what it means, for example that:
- certain features are not available to them
- Notify as a whole is not available to them
- they are using a ‘different’ version of Notify to those using it for
real
In the most severe cases this ambiguity actively dissuades users from
adopting Notify. We know this from support tickets and user research;
there are probably a host of other teams we haven’t spoken to.
Here’s a quote from a user research session just last week:
> Once we’ve got the facility to receive inbound messages […] that’s not
> available to us at the moment with a beta account
From support tickets:
> We see that the service is still in beta mode – can we assume
> uninterrupted service reliability and performance?
> we do not have a .gov.uk email address any longer but I was wondering
> if we would be able to utilize the notify system which is currently in
> beta
> We are currently using the BETA version, are we able to switch to the
> TEST version so we can add other numbers to send SMS to?
> I have previously enquired about this option [receiving text messages],
> but thought it was still at Beta stage. If we can set it up so that
> notify handles the responses that would be great.
> [after going live] Should I see the wording LIVE on the login screen
> as I still see BETA.,....
> Also I note that you are a BETA service just now and that to use the
> service we would need a .gov.uk email address. We don't have this, is
> there any way that [redacted] could use the service as I note that one
> of the teams have an account?
---
This commit removes the beta badge from Notify, and hopefully with it
the confusion it’s causing our users.
