-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contractions #266
Comments
A few comments below this blog post: https://gds.blog.gov.uk/2016/02/23/writing-content-for-everyone/
|
From the NHS Login team (sent in via Slack): |
The DH guidance on writing for people with learning disabilities says: "Do not use contractions and avoid apostrophes, except where they indicate possession." I'm preparing the slides for the Style Council meeting, with a suggestion that we consider adding the following to the style guide: "Be aware that some people struggle to understand contractions like you'll, we'll, you're and what's, even though contractions can make content friendlier. Do not use them if your users are more likely to have low literacy or a learning disability. (This doesn't apply to apostrophes for possession, such as "your child's health".)" But shouldn't all of our content be easy for people with low literacy to understand? Also are we happy to say that we do not use contractions in H1 headings, page titles, or urls? Here's an example of a url that includes a confusing contraction: |
We (111OL) have not seen users struggle with contractions at all. We use them carefully and make a judgement about when and where they are appropriate. Content seems friendlier with contractions, that is true. But it's not just about colloquial style - it's also easier to read. Expanding all the contractions within a bit of content makes it seem hectoring, and unnatural. It makes reading more of a conscious undertaking than the absorption of information. We get in the way. I am careful about using negative contractions, and aware of all of those that are hard to scan, but in the main positive contractions are a useful part of grammar. Not using them would fundamentally change the tone of what we are trying to convey. Guidance for content designers on when and when not to use them is fine. But in my view the evidence is not yet strong enough to suggest that very many people struggle with them. |
I've also spoken to my friend who has been teaching ESOL for the last decade. The idea that non-native speakers find contractions hard is not always true. That's an oversimplification. If their native language does not use contractions they might find it harder. But that is not true for all languages. |
Re. using contractions in URLs The Information Architecture team on the NHS website are currently drafting URL standards (for the NHS website). We're relying heavily on GOV.UK URL standards https://www.gov.uk/guidance/content-design/url-standards-for-gov-uk The main principle for URLs is that they should mirror the title of the page (h1). This is to support users placemaking within the website (as the URL should be a canonical representation of where they are) - and also a reference point if the user was trying to find the same page again via their internet history. The first standard in GOV.UK's policy and one we're looking to adopt will be
The websites SEO consultants have recommended that
With this in mind, contractions without apostrophes are hard to read, unclear, not easy to type and therefore not easy to share. For example
Also, some contractions without apostrophes spell out words different from their full form meaning - which again is hard to read, unclear and also causes ambiguity. For example
We also need to take into account assistive technology - if a screen reader reads out a URL without correct apostrophes - giving the listener a different meaning, would a user be less likely to visit said page? Or if a user with voice input is trying to visit a specific URL - would we expect them to spell out a word without contractions? For these reasons, I believe we should avoid contractions in URLs and possibly consider these examples when deciding on having contractions in our page headings (h1's) |
Positive contractions - Style Council decisionAt the November Content Style Council meeting, we reviewed the issue of positive contractions. There was a range of feedback on the information on this ticket. Sara agreed to take comments away and come back with a proposal for the content style guide. Here is the proposed wording. Please let Sara know if you agree that we can add this to the style guide. "There is evidence that some people struggle to understand contractions like you’ll, we’ll, you’re and what’s. Consider your audience, tone and context. You might want to use contractions because they make content friendlier or if you’re short of space. But do not use them if you think your audience might have problems with them, for example, if you’re writing for people whose first language is not English or people who have a learning disability." We need more evidence before we can take a stronger position than this. I will put this wording back in front of the content designer community before sending it for clinical approval. |
Contractions in URLs and page titlesAt the November Content Style Council meeting, @bencullimore introduced the issues noted on this ticket. We agreed that we would be clear that contractions must not be used in URLs and that we would advise against using contractions in page headings/H1s. We need more evidence (including about the difference between transactional versus static content) before making this a firmer rule. A review of H1s on the LiveWell site and Common Health Questions showed that very few currently use contractions. Sara took away the comments at the meeting and said that she would come back with some proposed text to add to the style guide. This is the draft wording: "Do not use contractions in URLs. They can be unclear, hard to read, type and share. Sometimes they are ambiguous, like 'shell' and 'were'. If you can, avoid using contractions in page titles and H1s too. Ideally the page title and URL should be the same." I'll put this wording back in front of the content designer community before sending it for clinical approval. |
Positive contractionsSince the Style Council meeting, we've had some further feedback about positive contractions and a proposal that we should not change our current practice yet but wait for more research. We'll hold off making any changes re positive contractions for now. Comment 1: The audience for any content (at least any content on nhs.uk) may be someone whose first language isn't English or who has a learning disability. I wonder if it's better to do more research on this before saying anything? Comment 2: I was going to say the same thing about audience. I would have liked to have been in the session for this.I’m not sure the proposed entry is helpful, what contractions will people not struggle with? I also wonder if the evidence we have for not using contractions in the context of a service is different than in a page of content. We don’t use negative contractions as there’s a risk someone could end up doing or not doing something potentially dangerous. Is there the same risk for positive contractions? I’m sure there are hundreds of pieces of content that have been tested that include positive contractions that have been understood. I think we do need more evidence to really make a decision. I don’t think we can say don’t use them because people don’t understand them, but you can use them if you’re short of space. Maybe we avoid them on services, or when we need people to take and action to be sure it’s clear. |
Contractions in URLs and page titlesWe have content designer and clinician agreement to publish the changes about contractions in URLs. The changes are included in this pull request. They should be published at the next release. |
Positive contractionsI'm putting this issue back into the To do column now for further research about positive contractions. |
We've had a suggestion that we remove "they've" from our list of contractions not to use. https://nhsuk.slack.com/archives/C2W772X8C/p1623669095084200 For next Style Council meeting? |
We've had a query about "you've" via the service manual Slack. Some other GOV guidance cover contractions but none specify "you've". https://design.homeoffice.gov.uk/content-style-guide#contractions But there was a suggestion that we avoid "you've" because other 've contractions have been identified as difficult to understand. Worth adding to style guide as this is the second time it's been queried? |
Discussed with the senior content team. Agreed not to take "you've" to Style Council for now. We use it a lot, especially in the context of "if you've had" and we haven't seen it being problematic. It is a bit different from should've, would've, could've which have the added complication of being modal verbs. |
What
https://dictionary.cambridge.org/grammar/british-grammar/contractions
Current service manual guidance states:
https://service-manual.nhs.uk/content/formatting-and-punctuation
Content designers on NHS.UK had a wide discussion around the use of contractions on the website. It was suggested that the advice in the service manual's style guide on contractions would need revisiting as NHS teams, inc. NHS login have observed people misreading them as have teams building other government services.
GOV's guidance suggests avoiding negative contractions https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style#contractions
Here's a ticket from HMRC with evidence of users - particularly those with low literacy, low vision and dyslexia struggling with all kinds of contractions hmrc/design-patterns#130
It was also suggested that content designers on the NHS website avoid using contractions as page headings:
We don't tend to use contractions in H1 headings because this style of heading doesn't make for a great page title. It's more likely to be used in an H2 or H3. However, if we were to use a contraction in the H1, we definitely wouldn't add it to the url.
But this guidance has yet to be captured formally.
The text was updated successfully, but these errors were encountered: