We’ve seen in letters usability testing that people get stuck in a
“no-man’s land” when trying to go back from the _Send yourself a test_
page.
This was broken for two reasons:
- we hadn’t considered that a letter template without placeholder still
requires you to fill in
- we’ve changed subsequently made the _view template_ page the place
where you do your actions, rather than the (old) page with all the
templates shown
So this commit fixes it so that the back link always take you back to
the page you were previously on, and adds some more test cases so we
have all the scenarios accounted for.
The breaking change page wasn’t properly accounting for the fact that
letter recipients span multiple columns – it was assuming they’d only
take up one column like they do for email and SMS.
This commit fixes:
- the number of column headers (A, B, C, …) to be correct
- the count of columns (you will need X columns in your file) to be
correct
It then parameterises the test to look at a case where a recipient is
in one column (email) and multiple columns (letter).
Users who go to edit the contact details for a letter from the template
page get very confused when they click save and are dumped on the
settings page. It doesn’t match the way editing other parts of
letter works, and you can’t see an accurate preview of the changes from
the settings page.
So this commit changes the flow to go from the _edit contact details_
page back to the _view template_ page when the user has got there by
clicking the blue _Edit_ button on the _view template_ page.
pass in the base URL - if not set in the environment this is set to
localhost, but on paas we can pull this out of vcap_services so that
letters render properly on paas
Tests assumed that the API returns the template `id` as part of the
object. It doesn’t – it returns it as the key used to look up the
object. The `id` was missing from the transformation into the format
used by the front end.
For some reason Flask is fine building the URL with `template_id=None`,
but obviously this doesn’t generate a valid link.
Not necessary to have it on its own page – it’s one line of stuff. And
definitely not as frequent use as the ‘Upload recipients’ or ‘Send
yourself a test’ links.
Letter templates have (or will have) multiple different editable
regions. I think that the most intuitive way for this to work is to have
- an edit link for each of these areas
- positioned next to the thing to be edited
Again, this isn’t fully hooked up, but since no-one is using letters
live yet this is a good way of getting research feedback and pointing
towards where we want the feature to go.
Uses percentages for the positioning so that the alignment is maintained
on mobile.
The links to the right of the template take up valuable horizontal
space. This means that the preview of email and letter templates isn’t
as big as it could be. By making the letter preview bigger it removes
the need to click through to the PDF to see a preview.
Reuses the navigation style used on the API integration page, because I
think it damages consistency to create another new button style.
When a team has lots of templates the choose template page gets very
long. It gets hard to find the template that you are looking for.
Our initial reckon was that teams would not be giving their templates
very useful names, and therefore a preview would be helpful. What we
have found is that:
- teams actually do give their templates useful names, and refer to
these template names elsewhere
- the previews are less useful for emails and text messages, because
they have so much content (which for emails also makes it harder to
`ctrl` + `f` the template name)
The other problem we found was that this page presented the user with
a _lot_ of options. For each template there were 4 actions, plus the
click-to-preview action for letters, plus the ‘see previous version’
action for templates that had been edited multiple times. It was a very
busy page.
And the final problem (that we recently introduced) was that there was
no way, other than the visual cues, to know whether a template was a
letter, email, or text message.
So this commit strips back the choose template page to be very focused
on finding the right template, by only showing the template name and
type. The user can then click through to a page that shows just a single
template, and perform actions relevant to that template from that page.
Although we integration test the pages that depend on these, it’s
probably a good idea to unit test them as well, to make sure, for
example, that all the different statuses are counted when working out
how many messages have been sent from a template.
The tour teaches you how Notify works by letting you do a thing and then
showing you the effect of the thing you’ve just done – a text message on
your phone.
This is not as effective if you don’t get the text message quickly. It
breaks the association you make between what you’ve done on the computer
and what’s happening on your phone.
Slow text message delivery can happen if you’re doing a big job. We can
get around this by making your text message use the priority queue.
This was observed in the pilot research session yesterday.
The breaking change page temporarily holds the changes in hidden inputs
on the page. The messages content it gets from the `.content` property
on the subject. This is raw and not transformed in any way, so fine.
For the subject it gets the value from the `.subject` attribute on the
template. For email templates, this will be transformed to highlight
placeholders with `<span class='placeholder'>…`. This means that when
the change is confirmed, it’s this encoded version that gets sent to the
API. Which is bad, because we then save `<span class='placeholder'>` in
the database.
This commit changes the page to look at the `._subject` attribute
instead, which is the internal, untransformed version of the subject.
The support flow was using `yes` and `no` to mean emergency/not
emergency. But not in all places – in one place it was using
`True`/`False` instead.
We were treating anything other than `yes`/`no` as a non-answer, which
means ask the question again. Because of the `True`/`False` thing, there
was no way of the user providing a valid `yes`/`no` answer. Which means
that we just kept asking them the question again and again and they got
stuck in a loop.
For some reason we were rebuilding `new_template` as a dictionary,
without the `placeholders` attribute. This meant that we were never
actually counting the placeholders, just counting the length of `None`
and adding 1 to it.
So this commit fixes that, beefs up the tests, and makes sure that
everything is pluralised properly.
41fa158635 added a proper Jinja filter
for formatting lists, which was better than the previous macro-based
solution.
It didn’t, however, account for HTML properly. It did the default Jinja
thing of escaping everything. Since we render lists of placeholders
by putting HTML before and after each item, this didn’t work (the HTML
got escaped and appeared on the page).
So this commit does the escaping of HTML outside Jinja, in the
user-submitted bits of the input only, then passes the whole thing
through as a `Markup` instance which doesn’t get escaped by Jinja.
no actual template functionality yet - just the ability for services
that have letters enabled to edit a 10 line block that will go on the
top right hand side of their letters with contact information
We’ve had a couple of instances where teams have sent the wrong template
to a …number of users.
Sometimes templates can be very similar and only have slight variations
to tailor them to a specific subset of users. So identifying the right
template by sight can be difficult.
We know that teams do give their templates meaningful names, and use
these names in other tools (spreadsheets etc) to refer to the templates.
So putting the name of the template on the page where you’re about to
send all the messages seems like it’s gives people an easier way of
double checking that they’re doing the right thing.
I umm’d and ahh’d over the wording a bit, and think ‘Preview of…’ reads
the best. It looks a bit weird because most template names are Title
Case. I think it’s better than some ambiguous punctuation (eg ‘Preview:
Template name’ or ‘Template name – preview’).
Some examples of real template names:
- Preview of Example text message templates
- Preview of Online LPA payment application reminder
- Preview of Create user account
- Preview of Split journey - Unknown credentials
- Preview of Public user: application without supporting documents
- Preview of Renewal Survey – February
- Preview of CEX New adult
- Preview of Applications are closing tomorrow
- Preview of Your application result - if successful
> Scottish Enterprise is Scotland's main economic development agency
> and a non-departmental public body of the Scottish Government.
– https://www.scottish-enterprise.com/about-us
For some reason their email domain is `scotent.co.uk` (but it redirects
to www.scottish-enterprise.com on the web for the some reason
¯\_(ツ)_/¯)
Right now we have separate pages for email and text message templates.
In the future we will also have a separate page for letter templates.
This commit changes Notify to only have one page for all templates.
What is the problem?
---
The left-hand navigation is getting quite crowded, at 8 items for a
service that can send letters. Research suggests that the number of
objects an average human can hold in working memory is 7 ± 2 [1]. So
we’re at the limit of how many items the navigation should have.
In the future we will need to search/sort/filter templates by attributes
other than type, for example:
- show me the ‘confirmation’ templates
- show me the most recently used templates
- show me all templates containing the placeholder `((ref_no))`
These are hypothetical for now, but these needs (or others) may become
real in the future. At this point pre-filtering the list of templates
by type would restrict what searches a user could do. So by making this
change now we’re in a better position to iterate the design in the
future.
What’s the change?
---
This commit replaces the ‘Email templates’, ‘Text message templates’ and
‘Letter templates’ pages with one page called ‘Templates’.
This new templates page shows all the templates for the service, sorted
by most recently created first (as before).
To add a new template there is a new page with a form asking you what
kind of template you want to create. This is necessary because in the
past we knew what kind of template you wanted to create based on the
kind you were looking at.
What’s the impact of this change on new users?
---
This change alters the onboarding process slightly. We still want to
take people through the empty templates page from the call-to-action on
the dashboard because it helps them understand that to send a message
using Notify you need a template. But because we don’t have separate
pages for emails/text messages we will have to send users through the
extra step of choosing what kind of template to create. This is a bit
clunkier on first use but:
- it still gets the point across
- it takes them through the actual flow they will be using to create new
templates in the future (ie they’re learning how to use Notify, not
just being taken through a special onboarding route)
I’m not too worried about this change in terms of the experience for new
users. Furthermore, by making it now we get to validate whether it’s
causing any problems in the lab research booked for next week.
What’s the impact of this change on current services?
---
Looking at the top 15 services by number of templates[2], most are using
either text messages or emails. So this change would not have a
significant impact on these services because the page will not get any
longer. In other words we wouldn’t be making it worse for them.
Those services who do use both are not using as many templates. The
worst-case scenario is SSCS, who have 16 templates, evenly split between
email and text messages. So they would go from having 8 templates per
page to 16, which is still less than half the number that HMPO or
Digital Marketplace are managing.
References
---
1. https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
2. Template usage by service
Service name | Template count | Template types
---------------------------------------|----------------|---------------
Her Majesty's Passport Office | 40 | sms
Digital Marketplace | 40 | email
GovWifi-Staging | 19 | sms
GovWifi | 18 | sms
Digital Apprenticeship Service | 16 | email
SSCS | 16 | both
Crown Commercial Service MI Collection | 15 | email
Help with Prison Visits | 12 | both
Digital Future | 12 | email
Export Licensing Service | 11 | email
Civil Money Claims | 9 | both
DVLA Drivers Medical Service | 9 | sms
GOV.UK Notify | 8 | both
Manage your benefit overpayments | 8 | both
Tax Renewals | 8 | both
The user has 10 tries at the password, after which the account is locked.
The same is true for the verify code, the user will have 10 tries before the user account is locked.
> When the CSV is missing the header row, we get an error and the user
> will see "Sorry, we are experiencing technical difficulties..."
>
> We should return a better error message for the user.
– https://www.pivotaltracker.com/story/show/140668615
This was caused by an attempt to access the `first_recipient` variable
before it was assigned. It would only be assigned when there was at
least one row in the file.
Fixing this means doing two things:
- defaulting `first_recipient` to be `None` before looking in the file
- adding an error message for when we can’t extract any rows out of the
file (which is more nuanced than the file just being completely empty)
(There’s a nasty `sort` in the Jinja template because when there are no
rows in the file the order of the required column headers is not
deterministic.)
specifically, the 2FA page when you first create an account is different to the login 2FA page
and also the 2FA page when you change your phone number is different as well
when a user enters their 2FA code, the API will store a random UUID
against them in the database - this code is then stored on the cookie
on the front end.
At the beginning of each authenticated request, we do the following
steps:
* Retrieve the user's cookie, and get the user_id from it
* Request that user's details from the database
* populate current_user with the DB model
* run the login_required decorator, which calls
current_user.is_authenticated
is_authenticated now also checks that the database model matches the
cookie for session_id. The potential states and meanings are as follows:
database | cookie | meaning
----------+--------+---------
None | None | New user, or system just been deployed.
| | Redirect to start page.
----------+--------+---------
'abc' | None | New browser (or cleared cookies). Redirect to
| | start page.
----------+--------+---------
None | 'abc' | Invalid state (cookie is set from user obj, so
| | would only happen if DB is cleared)
----------+--------+---------
'abc' | 'abc' | Same browser. Business as usual
----------+--------+---------
'abc' | 'def' | Different browser in cookie - db has been changed
| | since then. Redirect to start
