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.
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/
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.
The HTML validator picks up this error in our code:
> Self-closing syntax (/>) used on a non-void HTML element. Ignoring
> the slash and treating as a start tag.
In pages specific to a service (e.g. dashboard and sub pages) the title
needs to distinguish which service it applies to. This is mainly to give
context to screen reader users who could be managing multiple services.
Implementing this uses template inheritance:
`page_title` includes `per_page_title` includes `service_page_title`
‘GOV.UK Notify’ is inserted into every page title.
Pages that set `service_page_title` get the service name inserted too.
Our support process is about to get more fully fledged so we’ll need
an index page to route people properly.
We reckon that users will also want to know what the support process is,
so let’s explain it on this page.
This is part of the new header style that Tim, Stephen et al have been
working on.
This means that we lose the feedback link, so I’m trying out having it
in the top right.
This link looked odd floating above the left column, and although we may want
to have admin navigation on the left we aren't sure what that would include
yet, so move this link to the header alongside the Platform admin link.
> Make the header bar red
>
> Red for admin is a good reckon.
– 286fc308d9 (part of https://github.com/alphagov/notifications-admin/pull/130)
Starting to think it’s not such a good reckon. Users could take a guess
at what it meant, but they often guessed wrong.
However, changing the colour of the header bar _is_ useful for us
internally to see which environment we’re in. So this commit makes three
changes:
1. On live, the header bar is always standard GOV.UK blue
2. On other environments, the header bar is some other colour (local is
very different, staging and preview are related colours)
3. If an enviroment has a different header colour, it has it even when
you’re not logged in.
Because users have difficulty getting back to the Notify admin
interface.
The `rel` attribute mitigates against [a nasty cross-domain
vulnerability](https://mathiasbynens.github.io/rel-noopener/).
If all our URLs are unique (because they contain service/job/template
IDs) then it makes it hard to aggrate how users are behaving across a
range of services/jobs/templates.
This commit replaces anything that looks like a UUID in a URL with `…`.
In research we found that developers orientate themselves around the
API clients rather than the documentation.
We should get them to the client documentation as quickly as possible.
We currently link to the API documentation in three places:
- API integration page
- global footer
- template ‘API info’ page
For the first two this commit:
- removes the link to the documentation
- adds links to each of the 5 clients
For the last one it just removes the link entirely.
