Skip to content
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

Hint text: Collate and review existing research #251

Closed
Tracked by #240
martinwake opened this issue Nov 9, 2021 · 4 comments
Closed
Tracked by #240

Hint text: Collate and review existing research #251

martinwake opened this issue Nov 9, 2021 · 4 comments
Assignees
Labels
🔗 component Reusable parts of the user interface that have been made to support a variety of applications. ⏱ days A few unknowns, but we roughly know what’s involved. hint text

Comments

@martinwake
Copy link
Collaborator

martinwake commented Nov 9, 2021

Existing practice on full stops

Should we use full stops in hint text? The options are:

- Always
- Never
- Sometimes

Always use full stops

One argument for this is based on screen reader behaviour. It is suggested that JAWS in particular needs a full stop to know that it needs to pause after the hint text. This seems to be a particular problem if there is also a validation error being displayed.

Counterpoint: there seems to be evidence on the other side too, that screen readers can actually handle this OK as long as the hint text is part of a separate HTML element. Some guidelines recommend omitting full stops but always testing with screen readers.

There is an ongoing discussion about whether to make hint text a <p> tag which will apparently help this, but for now in GOV.UK frontend it will be a <div> tag.

Another argument for always using full stops is that it works better where hint text contains more than one sentence. It's clear that the first sentence should end in a full stop, but if the second one doesn't, does the inconsistency cause problems or friction for users?

Counterpoint: hint text should never be long enough that it needs two sentences. If you need to write two sentences, you're not writing hint text any more.

We could restrict the use of hint text to helping people avoid validation errors in a particular field. If you need to explain more about a question, for example where to find information or what the question means, then you either need to use body text or rethink the question. In practice, though, designers won't always be able to do this.

Some guidance that argues for full stops (including Universal Credit) makes an exception where the hint text ends with an example: this is based on reported (though not very well documented) user behaviour of including the full stop when entering data into the field, and thereby triggering validation errors.

"Enter a postcode in the correct format, for example SW1A 1AA."

The NHS guidance says this problem has been observed but without giving more detail. In contrast, HMRC reports user research where the lack of a full stop was distracting and drew users' attention because it looked like a mistake.

Never use full stops

The main argument for this is stylistic consistency with error messages and other text that might generally be called "UI copy". This is seen in guidelines from Microsoft and the Office for National Statistics, among others.

NHS quotes Amy Hupe https://twitter.com/Amy_Hupe/status/1238418276490915841 on why error messages don't have full stops (nhsuk/nhsuk-service-manual-community-backlog#17):

"Needless to say, this approach isn’t perfect. For example, if you have a 2 sentence hint, it’s tricky: should you include a stop on the end of the second sentence or not? Or if the hint or error contains a question mark, what then?"

The main focus of this discussion is whether validation errors should have full stops: hint text is only involved because the preference is for hint text and validation errors to be consistent with one another. If we don't mind about that, then perhaps we don't have to do the same thing in errors and hint text.

Use full stops except with example formats

The systems that recommend this all seem to have "use full stops" as the default, with special cases where you should omit them. I couldn't find any examples of the opposite position. Systems that recommend leaving them out don't seem to acknowledge special cases where they should be included.

Draft guidance for NHS content guidelines reads:

"If you're using hint text or error messages to tell users how to enter information in a text input box, with an example, and there is a chance that users will copy the full stop and this will cause validation errors, do not end your sentence with a full stop. Example: "Enter a valid post code like SW1 2AA" with no full stop.

This is also the position we take in the Universal Credit guidance:

"Use correct grammar and punctuation, including full stops. The exception is for examples of formats (like the date format.) These should use this pattern:

For example, [give example]

No full stop."

@martinwake martinwake mentioned this issue Nov 9, 2021
22 tasks
@martinwake martinwake changed the title Collate and review existing research Hint text: Collate and review existing research Nov 9, 2021
@jonhurrell jonhurrell added ⏱ days A few unknowns, but we roughly know what’s involved. ⛓️ pattern Best practice design solutions for specific user-focused tasks and page types labels Nov 10, 2021
@martinwake martinwake self-assigned this Nov 10, 2021
@martinwake
Copy link
Collaborator Author

Spoke to UC about their guidance for hint text and will see what we can use from their experience.

@martinwake
Copy link
Collaborator Author

martinwake commented Nov 26, 2021

Comment text moved to description

@jonhurrell
Copy link
Collaborator

Now that this ticket is done, do we want to move the insights to a discussion, so it's doesn't get lost in a moving ticket.

@martinwake
Copy link
Collaborator Author

Now that this ticket is done, do we want to move the insights to a discussion, so it's doesn't get lost in a moving ticket.

Moved to community backlog discussion at https://github.com/dwp/design-system-community-backlog/discussions/81

@martinwake martinwake added 🔗 component Reusable parts of the user interface that have been made to support a variety of applications. and removed ⛓️ pattern Best practice design solutions for specific user-focused tasks and page types labels Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🔗 component Reusable parts of the user interface that have been made to support a variety of applications. ⏱ days A few unknowns, but we roughly know what’s involved. hint text
Projects
Development

No branches or pull requests

2 participants