URL guidance (currently focused for the NHS website) #265
Comments
|
A finding from the NHS website's Information Architecture team is that URLs should mirror the site structure and page headings. @karlgoldstraw identified instances where contractions such as Finding out you're pregnant were being used as page headings and queried how these should be reflected in the URL:
Karl checked with our SEO consultancy who suggested that apostrophes should not be used in URLs. The SEO consultant suggested that both options without the apostrophe would be fine from a search engine perspective. Content designers on NHS.UK had a wider discussion around the use of contractions on the website in general. It was suggested that the advice in the service manual's style guide on contractions would need revisiting as NHS teams have observed people misreading them, as have teams building other government services. It was also suggested that content designers on the NHS website avoid using contractions as page headings:
But this guidance has yet to be captured formally. |
bencullimore
added
Information architecture
|
+1 for this, this is something I've come across needing again and again during the coronavirus projects. It's common that production URLs are just being the made as whatever the prototype URLs were, but this isn't the right approach as a prototype is usually just a quick and easy name that someone has come up with. Having a standard would be very beneficial. |
|
From an IA perspective, the structure of the website shouldn’t be masked through shortened, truncated addresses. URLs should be a canonical representation of where the page sits. For example, hypothetically - if you have a fingernail removal service and structurally this service belongs to the finger section, the main and URL should be
By masking the location of that specific page through the URL we will break a number of things
By breaking these things we’re hindering our user's ability to navigate our website. In this hypothetical example, a user might want to find out about nail removal but not actually book an appointment to remove their nail (just yet). By breaking IA, navigational elements and SEO we’re stopping them from finding the thing they need. User-friendly/Vanity URLs
|
|
With canonical URLs in mind, how best should we structure transactional service's URLs beyond the start page? For our hypothetical start page we have www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service with redirects from our vanity url www.nhs.uk/nail-removal-service Should subsequent service URLs follow the proper URL? For example or do we revert to the vanity URL? This question was discussed internally with input from technical and design leads. Here's a few comments:
|
|
The NHS websites SEO consultants have provided guidance supporting the Information Architectures team's principle of
Their advice is as follows: In SEO, we usually recommend organising content into “hubs” – having a parent / child page structure and grouping content thematically. This is because:
However, it’s worth saying that this would create more levels of landing pages in the site (e.g. a page each for hands, fingers, nails), that would also need to be designed. In SEO we used to suggest content by grouping keywords, but now we group by topics, as this is more similar to how Google’s entity / knowledge graph works. Ultimately, we recommend organising content and creating landing pages based on search volumes. For example (not a true / tested example!): “more people search for body parts, like hands, than symptoms, like itchy skin, so that’s how we will group content”. Other important SEO considerations
|
|
I've detailed considerations around the use of contractions in URLs here: #266 (comment) |
URL standards for the NHS website (nhs.uk) (draft)How URLs are used on the NHS website (nhs.uk), their formatting requirements and why short URLs are sometimes created for promotional purposes.
The NHS website (nhs.uk) URL style
a) URLs always need to be clear, unambiguous, easy to read, easy to type and easy to share b) all URLs must be in lower case c) URLs must use words and should not contain acronyms, wherever possible (see 8 for an exception on the NHS acronym) d) dashes should be used to separate words within URLs so they are easy to read - for example, https://www.gov.uk/set-up-business (need NHS example) (see 5, 7 for exceptions on campaign landing pages and service sub-domain URLs) e) articles (a, an, the) and other superfluous words should not be used. For example, use /benefits or /benefits-guides rather than /a-guide-to-benefits (need NHS example) f) URLs should use the verb stem, where possible. For example, /apply instead of /applying g) each page must have a URL which is as short, memorable and unambiguous as possible, especially if a URL is going to be referred to offline h) URLs should be based on user need rather than the (current) name of a policy, scheme or service, which might change. For example, the URL https://www.gov.uk/advertise-job is intended for people who want to advertise a job on the Department for Work and Pensions’ (DWP) Universal Jobmatch service (need NHS example) Campaign sites and URL promotion
‘Friendly’ URLs (furls) and redirects for existing content
The NHS acronym
Good: https://www.nhs.uk/about-us/nhs-website-datasets/ Top-level redirects
a) the URL conforms to all other requirements of the NHS website (nhs.uk) URL policy b) the content being promoted originates from, or is significantly relevant to, more than one department or organisation c) the URL needs to be specific to the content and make sense forever. For example, include a year when using a re-direct for one-off promotion of an annual event d) the URL will be used for significant offline marketing and promotion Query string parameters Canonical URLs
Governance Service URLs
Running the entire service journey under the canonical URL path for example www.nhs.uk/health-a-to-z/hand/finger/nail/nail-removal-service complicates things technically - ensuring the users requests get to the right backend/third-party application gets messy. Particularly when routing to different services behind the scenes throughout the journey. We would be introducing risk and complexity. Transactional service pages should not have a presence in the site other than the start page as a user will need to follow a transactional flow, only reaching specific URLs when answering questions or 'logging in'. In service scenarios a user shouldn't jump forward in a journey. In the example of a transactional service following a start page on a canonical URL, subsequent service URLs can be truncated. E.g. |
|
One issue we’ve come across is around vanity or “friendly” URLs – URL addresses set up to promote specific campaigns, for example, www.nhs.uk/friendsandfamily These URLs are used on marketing materials; posters, leaflets etc. which have been dictated by Marketing teams. I don’t believe these URLs are accessible – from the perspective of someone with access tech either having to read them out from a poster or use them to navigate to a webpage. I recall a campaign a few years ago asking people to use upper and lower case characters in hashtags to support access needs… which we could employ, meaning the URL would become nhs.uk/FriendsAndFamily but, in the context of a URL; I’ve been advised that upper case characters are classed as ‘special’ and may cause technical issues. |
Vanity URLs continuedAfter an extensive debate on cross-government slack with experts in accessibility and security, with no evidence-based decisions on what makes a good vanity URL yet. With point number 3 of the URL policy in mind:
We have potential options:
I discussed having multiple vanity URLs based on promotional channel (voice; tv/radio/web, print; newspaper/letter) creating versions with and without hyphens, with the intention that the version with hyphens will be used in printed materials (hypothesis = easier to read) and the version with no hyphen will be used when spoken with National Cyber Security Center. They raised concerns about having multiple/similar variants of an address - for example if a user sees the URL in a letter and gets an SMS with a link - if the two don’t match they could potentially cause distrust (they had no evidence to this). Issues with having the URL without hyphens when spoken - does the speaker have to preface the address which multiple joined-up words with “no spaces?” I’ve been testing URLs without hyphens. Some try to pronounce them as a new word |
Tosin-Balogun
added
the
Priority!
|
This was ranked joint 5th from the |
|
Update on ‘Friendly’ URLs (furls) and redirects for existing content We've reached out to several accessibility experts including Nomensa and haven't found any specific guidance around what makes an accessible, friendly URL - in the context of promotional @mcheung-nhs the accessibility lead for the NHS website has run tests with the potential options detailed in my post above using JAWS, NVDA and Apple Voiceover, here's a link to his test page https://mcheung-nhs.github.io/accessibility/tests/urls.html We've noted issues around the use of lowercase acronyms - for example nhs.uk/stiscreening is incomprehensible by all screenreaders (they try to read stiscreening as a word), only when the acronyms are upper case (nhs.uk/STIscreening) it can be understood. There's inconsistency with hyphens on screenreaders - Apple Voiceover doesn't read them out, so nhs.uk/covid-vaccine is read out as "covid vaccine" which could lead to users inputting the wrong URL. All lowercase URLs are problematic too, dependant on the words some screen readers will try and pronounce as a new word, as mentioned previously - www.nhs.uk/malecondom sounds like "mallaécondom" The only option which appears to be consistent across all three screenreaders is the use of upper and lower case letters or camel case. The use of camel case is also supported by the RNIB who has published guidance on using CamelCase in hashtags > Use CamelCase in hashtags
I've discussed the above findings with the Accessibility Working Group at NHS Digital and it was recommended that try and reach out to dyslexia charities to understand what problems camel case might cause. |
Expanding the discussion to services / staff-facing servicesFrom discussion on Design Slack So I see the recommendation for us in NHS is The HMRC discussion goes for a more specific Given that the more complex services have additional depth, and also ours is staff-facing so doesn't hang off the website, we are proposing the homepage to our internal service (temporarily titled 'Create and manage identities') would be:
and the page title would be
And then an example of a subsequent page would be
|
|
Next question |
|
At the December Design System Working Group session, URL guidance was presented by @bencullimore. This was discussed and voted on by the DSWG members. Key points of discussion:
Vote to publish:5 - Ready to publish now Next steps
|
|
Asked people in the #dev channel on the NHS.UK Slack workspace for experiences of setting up URLs for NHS services to look at the proposed guidance for URL standards on this issue and share experiences where it wouldn't have been able to be followed, so we know if the guidance needs adjusting to better suit developers in the NHS |
|
@ethanmills on the UK Government Digital Slack added:
Possibly something extra to include in the URL standards. |
|
Maybe a separate topic but should there be guidance around domain names? An obvious one for most of us but it's very common in the GP website space; use Also subdomains, such as |
|
GP practices - they're private businesses so unsure if they're able to have NHS domain URLs. Would need to work with Policy/contract teams to understand the implications of this. In the COVID service example, I believe the URL was linked to commissioning/budgets. It was also created prior to the URL standards being published, some great points - especially around trust. I'll speak to the COVID pass team and see if they've had any user insight around URL trust. |
|
On the subject of Camel Case for friendly URLs, I am about to request a short URL for https://www.nhs.uk/conditions/coronavirus-covid-19/self-isolation-and-treatment/ but I feel that www.nhs.uk/SelfIsolation is probably more difficult to read than www.nhs.uk/self-isolation because of the upper case I and its proximity to the lower case l and f. |
Thanks for this @jiggott :) In this case, the following point in the drafted standards should cover using dashes and not Camel Case:
|
|
A few comments on the draft guidance above. (I'm reading it with a Publishing Platform issue in mind.) How would someone find out about the separate standards for the wider nhs.uk domain? Are there some wider standards? The draft above says not to use "a, an" etc. On our start page pattern, we have a small section on urls. We should make sure it's aligned with these URL standards when published. At the moment, it includes an example which does contain the word "an": https://www.nhs.uk/nhs-services/hospitals/book-an-appointment.
We have other examples that don't include "a" or "an", e.g.
How important is it that we avoid "a" and "an"? In https://www.nhs.uk/nhs-services/online-services/find-nhs-number/ we left out "your". In the "furls" section, point 7, would we want to mention: https://www.nhs.uk/referrals (used in the start page example)? |
|
A few other thoughts about the draft standards:
|
|
One possible benefit to using short URLs in comms to citizens is that they can reduce costs of sending SMS by helping to keep messages short. (Sending SMS is usually charged per 160 characters.) |
|
I wonder if sometimes we go too far on nhs.uk in using the H1 of a page for its URL slug. Once you get a few levels down this can result in really long URLs, eg: To my mind, both these URLs duplicate info about the content of the page and therefore make it harder to scan and get an idea of what you'll get if you click on them. They could both be shortened to something like this: Thoughts? |
I imagine this fits in with the longer-term work the Information Architecture team is doing to create a "polyhierarchical structure" (flattening the NHS website's structure) which would likely impact URLs created on the NHS website and align with your suggestions that remove unnecessary duplication @jiggott. @BrieWhyatt have I covered this correctly? |
|
Absolutely right @henocookie. Once we have everything sitting in the root folder, it will eliminate the start of the slug /conditions and allow URLs to more directly reflect the content - i.e. things that are currently in the /conditions folder that aren't conditions will no longer have that slug. This will make the URLs marginally smaller while also ensuring that information scent and relationships between content are more accurately represented. GOV service manual advice also states to not include 'a', 'an' 'the' in the URLs as they are superfluous to understanding. I wonder whether, in this instance, we should look at other words, such as the 'with' in the example James has given above, and consider whether these are also redundant. |
|
Looks like NHS Digital has a role in domain wide network addressing/URLs: https://digital.nhs.uk/services/networking-addressing. |
|
A conversation on the NHS.UK Slack channel: https://nhsuk.slack.com/archives/C6S0QTW9X/p1644933368349049. In short, don't shorten URLs unless you've got evidence they're a problem. Also leave in a/an if not causing problems. Have I captured that correctly @rhiannonsmith? |
henocookie
changed the title
|
Sent a message on the NHS service manual Slack workspace asking for people who have worked on the design, research or development of creating URLs for website pages or transactional services in the NHS, to help move this forward 😄 |
|
We're looking at having 2 vanity URLs, directing people to the same place:
|
|
Related issue: URL - the acronym #523 |
|
Re camel case, most users seem to default to typing in lower case and apparently a lot of browsers default to lower case too. We've seen someone type in a URL which the browser changed to lower case, so it didn't work where we had a camel cased jump link url. |
What
We need URL standards for the NHS website (NHS.UK)
This includes, how URLs are used, their formatting requirements and considerations around short URLs for promotional purposes (see nhs.uk/coronavirus)
References:
Open University: http://www.open.ac.uk/about/digital-governance/digital-standards-and-guidelines/url-standard-public/url-best-practice
GOV.UK: https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk
Why
URLs are important, especially in a health information context where users need reassurance that the information is trustworthy.
URLs always need always need to be clear, unambiguous, easy to read, easy to type and easy to share.
There currently isn't a standard for URLs on NHS.UK in place
Anything else
The Information Architecture team on NHS.UK has been using GOV's URL standards as a baseline https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk but feel aspects could be tailored in regards to users with health needs.
We should adopt the GOV.UK url policy.
Relevant sections for the NHS Website are 1-11, 12-16 are relevant for other parts of the NHS.
https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk
Exceptions
GOV.UK's policy 3. c)
URLs must use words and should not contain acronyms, wherever possible.
"nhs" should always be used in URLs instead of "national-health-service"
Good: https://www.nhs.uk/about-us/nhs-website-datasets/
Bad: https://www.nhs.uk/about-us/national-health-service-website-datasets/
Additions
Query string parameters
Use of query string parameters should be avoided where possible
Canonical URLs
Where the same content can be accessed through multiple URLs we recommend you define a canonical URL for the content, or equivalent content. (A canonical URL allows you to tell search engines that certain similar URLs are actually one and the same)
https://support.google.com/webmasters/answer/139066?hl=en&ref_topic=4617741
Governance
Both GOV.UK and Open University have a governance process for top level URL redirects to prevent conflicts and exhausting common words.
NHS does not - perhaps it should.
One thing worth pointing out is that good, user-friendly URLs are the result of good information architecture - they're the programmatic representation of meaningful structures and information relationships which have been properly researched with users.
The text was updated successfully, but these errors were encountered: