We have tickets from people asking how long the process takes. I suspect
that this is because they’re not getting to the bottom of the form
before they’re ready to go live.
A lot of users aren’t reading or paying attention to the checklist on
the request to go live page. We think that we can get more people to
read it by putting it on its own page, where users won’t jump straight
to filling in the form.
This will, later on, let us make this page smarter by automatically
detecting if they’ve done the necessary things.
MoJ O2 Transition Project – Ministry of Justice
Academies Financial Reporting Division – Department for Education
Money Claims Service Line – HM Courts & Tribunals Service
HR and Organisational Development – Calderdale Council
Family & Civil Service Line – HM Courts & Tribunals Service
Electronic Patient Discharge Questionnaire – Public Health England
previously we were just using the wtforms builtin email validator,
which is much more relaxed than our own one. It'd catch bad emails when
POSTing to the API, resulting in an ugly error message. It's easy work
to make sure we validate email addresses as soon as they're entered.
It’s weird that `/services/<service_id>` returns `404`. The home page
for every service is the dashboard – should be possible to get there
from any other page just by stemming the URL.
Also makes it consistent with organisations, which will have
`/organisations/<org_id>`.
Notifications-api now needs the service_id to check the uniqueness of
the service name when trying to change it. This is to allow a user to
successfully change the pluralization or the case of their service name.
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.
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 pin pointed the problem to a bad loop that was calling the format_phone_number_human_readable 216 for 25 rows, yikes.
This PR fixes that performance problem.
In research we saw developers having difficulty getting back to Notify once they’d
navigated to the documentation.
One way we think this might be alleviated is by keeping Notify open in the same tab,
and having the documentation open in a new tab.
It’s polite to tell users that this is going to happen.
`rel=noopener` stops the site we’re redirecting people to (Github) have script
access to the orginal Notify tab (see https://mathiasbynens.github.io/rel-noopener/ )
original Notify
We have a team who want their (short) web address as the text message
sender. This commit updates the validation of text message senders to
allow `.` as a valid character, which is currently blocking them from
doing this.
We can be fairly confident this works because:
- the team are sending large volumes of messages already with their
existing provider
- we’ve tested it with all combinations of
- both our text message providers
- an Android phone and n iPhone
