This proves to Google search console that we own this domain, and will let us start getting some more insights about how and when Notify appears in search results.
These are the settings that our analytics person has said we should be
using across all the GaaP products.
This commit also makes sure our tracking code is identical across all
the templates that have it in (including the obsfucation of UUIDs). We
may want to remove the ID obsfucation later on, but for now let’s make
sure it’s happening consistently in all the places.
Linebreaks are an important part of the letter contact block, and make
it easier to read.
Bold text works for short pieces of info like email addresses or phone
numbers, but is too heavy for the letter contact blocks because they
tend to be longer.
We used to say ‘None’ if this was empty. Now we say ‘Not set’. The thing
that decides whether to make the text grey or not was looking for ‘None’
(the old thing).
So that we can default services to their appropriate text allowance, we
need to find out what sector they're in. So let's start collecting that
from teams as they create new services.
I think Central/Local/NHS are the right options, but these can be easily
changed if not.
In user research, we’ve seen users copy/pasting the contents of the
inbound SMS page into a spreadsheet, in order to keep a record of the
messages they receive. They even went as far as to write a macro which
fixed the errors caused by copying and pasting.
It would be much easier if we just gave them the data already in a
spreadsheet format. Which is what this commit does.
One caveat is that, because spreadsheets can contain executable code (ie
formulas), and because we’re populating the spreadsheet with
user-submitted data (albeit via SMS) we need to be careful about
injection attacks.
The details of how these attacks work are detailed here (interesting
reading): http://georgemauer.net/2017/10/07/csv-injection.html
The mitigation is to not allow characters which initialise a formula
at the start of the cell.
This commit:
- uses WTForms email fields wherever we collect email addresses
- makes sure we don’t let the default HTML5 form validation get trigged
(using `novalidate`[1])
We don’t want to use the default validation because:
- it looks out of place
- it’s not well supported by assistive technology
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form#attr-novalidate
Entering, or reading back sequences of digits is easier when they’re a
bit more spaced out.
This is because we read words as shapes, but read numbers
digit-by-digit.
So this commit adjusts the tracking of the type to put a bit more space
in for textboxes that are going to accept digits.
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.
Notify is now available, as a pilot, to local government and the NHS. So
telling people that it’s only for government departments and agencies is
- wrong
- might stop them from signing up
The word ‘organisation’ matches what’s used on the list of services, and
on the hint text on the email field on the sign up page.
If you’re using inbound SMS then I reckon it’s useful to be able to
naviagate from one message to the context in which that message sits
(ie the conversation).
This commit adds that link.
This is maybe a stopgap until we do something more like chat, where you
can reply on the same screen where you see the conversation, but maybe
it turns out we don’t want to do that – lets see how this works.