Features is a sales tool. Once you’re using the product already there’s
less of a need to see it. The pages are still accessible from the
footer, and for users who aren’t signed in.
It doesn’t make sense to have a section called ‘Support’ which has a
link called ‘Support’ in it.
And by splitting up, and reducing the number of links in the footer,
they don’t _need_ headers – hopefully they’re self explanatory.
Email auth is a new feature that currently we’ve only given to teams
who have contact us with a problem.
At the moment, we’re aware of all the teams that are sharing phone
numbers when they sign in. We think that in the future there will be
other teams who encounter this problem. So we should let them know that
they should contact us if they are having the problem.
At the moment we want to talk to teams before giving them access to the
feature, so that we’re confident it’s only going to teams from whom it’s
more secure than using a text message code.
- Removed the code for the template_history endpoint and replaced with a
redirect to the new page so that anyone is forwarded on
- Updated the template to point to the new template_usage page
Department for Education – Find a Career
Gravesham Borough Council – Gravesham BC
Crown Commercial Service – CCS Power BI
Department for International Trade – Export Support Alpha
Crown Commercial Service – GCloud Assurance
* if the service issuing the invite does not have permission to edit
auth types, don't let them do anything. This will stop them turning
existing email_auth users back to sms auth
* if the user hasn't got a mobile number, but the invite is for sms
login, don't do anything either. They won't have a phone number if
they signed up via an email_auth invite previously.
in these cases, we accept the invite and add the user to the service
as normal, however, just don't update the user's auth type.
If we’re going to ‘disable’ radio buttons then we should always tell
users why the radio button is disabled.
This is what we found with the API key choices anyway.
Google tries to auto-generate a snippet of a site’s content to show in
search results. Currently it’s not doing a great job of this for Notify.
There’s a chance that if we give it better content in the site’s meta
description then it will use that instead. Worth a go…
The content is adapted from the blue box on the product page.
It’s 145 characters, which is within the 160 characters recommended[1]
It matches the content in the page, and contains words that users are
likely to be searching for (GOV.UK Notify, emails, text messages).
It’s only on the homepage, because it shouldn’t be duplicated across
multiple pages.
https://yoast.com/meta-descriptions/
