alerts-component.md

Alert component

This is an investigation in to alerts and an alert component that builds on the conversations in alphagov/govuk-design-system-backlog#2

Alert behaviour

After an audit of common alerts used across portfolio products, services and other government product the following behaviours for alerts have been observed

• Alerts respond to an action a user has carried out, like user input
• Alerts require a specific action or set of actions from the user and are not passive
• Alerts are context-specific
• Alerts can be persistent or dismissible
• Alerts should draw focus to it

These behaviours, to some extent, distinguish alerts (for example, error summaries) from banners (notifications)(for example, confirmation panel).

Alerts vs notifications

Some use cases mentioned in the backlog could be better served by developing a banner (notification) component. Reasons being that banner notifications aren't necessarily tied to a user's action while an alert should always be.

Notifications with alerting behaviours

Speaker to other designers across government, it seems there's more need for a notification component (this need is reflected in the examples presented in the backlog), rather than an alert component.

Adam Silver of MoJ suggests "A Notification component that can be turned into an alert. That is, it becomes focusable for example like the error summary."

Notification components already exists in other design systems

https://moj-design-system.herokuapp.com/components/banner

http://hmcts-design-system.herokuapp.com/components/banner

Alerts and notifications are often used interchangably, so I think it's important to be prescriptive about what alerting behaviour should be (in the Design System) to help determine its presentation and functionality. However, behaviour alone does not a component make and so coupling the alerting behaviour with a notififcation component fits with the expectation of users of design system, while also meeting some articulated needs.

@dashouse, still forming my thoughts but I'm leaning in the direction of alerts as a separate thing with quite precise behaviours similar to the error summary.

I'm also thinking the confirmation panel could be a variation of a parent notification component that also covers in page banners and boxed content.

Update: After more thought and investigation, I'm leaning towards a generic notification component with various attributes like alerting, confirmation, etc.

This looks awesome, @DebsDee. Like you, I'm leaning towards a component called ‘Notification’ that can be configured to be alert like.

That way we can use them in multiple contexts and positions...

Here's a place where we prompt the user to do something that's quite complex to do. (Ideally, we should design the interface so that they don't need instructions like this but this is quite a complex interaction.)

Here's a positive ‘alert’ notification in response to the user doing something:

Here's a notification that shows an application status to the user:

Here's a notification that prompts the user to do a thing:

Thanks for feeding into this @adamsilver, much appreciated. The examples you shared match with some of the notifications we use in some our portfolio products (though we don't use logos much).

Are any of these set up as an alert – no further actions can be taken until the cause of the notification is resolved?

From an accessibility pov I've checked out MDN's docs on the aria role for alerts: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_alert_role

I think it's useful in helping to further define what an alert is and when one should be used, which helps to define an alert 'modifier' on a notification component.

The alert role is used to communicate an important and usually time-sensitive message to the user. When this role is added to an element, the browser will send out an accessible alert event to assistive technology products which can then notify the user about it. The alert role is most useful for information that requires the user's immediate attention, for example:

• An invalid value was entered into a form field
• The user's login session is about to expire
• The connection to the server was lost, local changes will not be saved

Thanks @DebsDee. Makes good sense to me.

Re: logos — yeah, I know we tend to avoid logos. We added them in this case to help provide a comparable experience for colour blind users. I recognise that the text is there as a fallback to explain whether the notification is positive, negative or neutral. But we think it would be quicker to recognise the nature of the notification with an icon.

Are any of these set up as an alert – no further actions can be taken until the cause of the notification is resolved?

I don't believe we have the aria attribute on these—but that's an oversight more than anything. I would say we should have this attribute on some of them. Like telling the user the successfully added a question. But not to instruct them to highlight to make a comment.

@adamsilver, ugh I meant icons not logos. Definitely see their usefulness, there's the 'warning' one in the warning text component, might be useful to suggest more icon assets for use in other contexts (notifications).