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 had a user report that the ‘inbound messages’ part of their dashboard
was appearing for a split second then disappearing.
This was caused by the Javascript on the page throwing an exception as
it was trying to re-render this part of the page. This meant it gave up
and rendered nothing.
The exception was caused by passing `undefined` as the second argument
to `.insertBefore`. This is acceptable in most browsers, but not older
versions of IE. This is fixed in the latest version of diffDOM (the 3rd
party library we use to do the AJAX stuff) by defaulting the second
argument to `.insertBefore` to `null`, which is acceptable in old IE
versions.
See the fix here: 8833d87e9d
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
