Add guidance for notification banner#2211
Conversation
|
|
Thanks for this, @edwardhorsford. It's looking good. :-) I've made some changes but have some queries too. (I mentioned some of them on Slack.) The GOV page talks about messages only in emergency. They use a COVID example but you mentioned it may be more about systems outages. I've avoided mentioning emergencies as there could be other reasons.(Though, as you said, the confirmation page might be a better place for this sort of messaging. I can put the wording around emergencies back in if you think we should. I’ve had a go at explaining that the component includes an H2 (usually) and why GOV says to use H3 for further headings. Does what I've said work? GOV's component links to Service unavailable and There is problem with this service patterns, which we don’t have. Should we link to GOV or not mention them? Is the "Patient outcome recorded" example a tested one? (It doesn’t have to be but helps if it is.) I wondered if the green success example should sit under the heading “Reacting to something the user has done” after the 1st sentence, followed by examples of when not to use it, e.g. in linear journeys. Re the WCAG2.2 info at the bottom of the page, we normally use the WCAG 2.2 blue tags (see buttons page). GOV got rid of them. Do we want to use our standard WCAG 2.2 treatment? I've not done the change log or What’s new pages yet. But I have added this page to the site maps. |
|
|
||
| <h2 id="telling-the-user-about-a-problem-that-affects-the-whole-service">Telling the user about a problem that affects the whole service</h2> | ||
|
|
||
| <p>Use a "neutral" blue notification banner if the user needs to know about a problem with the service as a whole.</p> |
There was a problem hiding this comment.
Might mention that 'information' can be used for other cases than problems. Eg system update messages.
There was a problem hiding this comment.
Maybe combine the blue banner examples under a heading and give it a line to explain more generally what the blue/neutral version is for
There was a problem hiding this comment.
Might mention that 'information' can be used for other cases than problems. Eg system update messages.
I'm wary of mentioning system update messages, apart from planned downtime. They tend to be overused to tell people things they're not interested in.
Added some comments inline
Do we have precedent of linking to govuk things where we don't have a page? If so I'd keep them, but otherwise we could remove?
No, I made it up. It's a bit similar to this that we have in my service (still in development). 
Sounds good!
Let's change for whatever our current format is.
Thanks! I think I meant to search where else this needs linking but forgot. |
| <li>something that affects them in particular (for example, an approaching deadline they need to meet)</li> | ||
| </ul> | ||
|
|
||
| <p>Use the green banner to tell the user that something they've just done on a previous page was successful (for example, confirming that an email has been sent).</p> |
There was a problem hiding this comment.
As above, would refer to this as the success banner, not the green banner.
There was a problem hiding this comment.
I'll update the branch to call them success banner and info banner.
| <p>Use notification banners sparingly. There's evidence that people often miss banners, and using them too often is likely to make this problem worse. See <a href="https://www.nngroup.com/articles/banner-blindness-old-and-new-findings/">Banner blindness revisited by Norman Nielsen Group</a>.</p> | ||
| <p>Use notification banners sparingly. There's evidence that people often miss banners. Using them too often is likely to make this problem worse. See <a href="https://www.nngroup.com/articles/banner-blindness-old-and-new-findings/">Banner blindness revisited by Norman Nielsen Group</a>.</p> | ||
|
|
||
| <p>Avoid showing more than 1 notification banner on the same page. Instead, combine the messages in a single notification banner. If the messages are too different to combine, only show the highest priority notification banner.</p> |
There was a problem hiding this comment.
If the messages are too different to combine, only show the highest priority notification banner.
I suspect this could be rather hard to actually make work in practice due to how banners are usually implemented.
There was a problem hiding this comment.
I take this to mean, only have 1 banner with your highest priority message.
There was a problem hiding this comment.
I'll tweak the wording. See what you think.
|
I'm not sure about this wording re the notification banner as a whole. "A notification banner lets you tell the user about something that's not directly relevant to the thing they're trying to do on that page of the service." The success banner is related to something you've just done. |
|
@edwardhorsford, with the success banner example, what do we mean by "patient outcome"? Is there another word we could use instead of "outcome"? |
Agree, I think it's more about the content of the page their on, rather than relation to their task. So a success banner would be on the next page when you, eg, create a new thing. Not on the top of the page where you made the thing. That's my understanding anyway. |
colinrotherham
force-pushed
the
add-notification-banner
branch
from
58336d5 to
2f9c91b
Compare
|
I've rebased this PR branch on top of our v10 breaking changes PR: i.e. It'll be combined with nhsuk/nhsuk-frontend#1408 once merged |
|
edwardhorsford
changed the title
5 participants
Adds a guidance page for the new notification banner component.
I've started by taking a copy of the GOV.UK guidance, updating namespaces to NHSUK, updating the examples to be more NHS relevant, and removing the section about contacting GOV.UK in an emergency.
It's added in the nav, but I need to check if there's anywhere else it should get linked from.
Some of the examples currently use
callsyntax, but I am worried about that being harder for novice Nunjucks users to understand. I've sought feedback for this on slack and will update the examples when we have consensus.Before merging
This PR relies on this PR to be merged first. This PR currently hardcodes package.json to that branch for the purposes of development. We'll need to remove that prior to merge.
Screenshot:
