Status message

[ollybeal]

Pattern (https://design.homeoffice.gov.uk/components?name=Status%20message) is being developed for an internal service where multiple users can see the same case - pattern is shown near the top of the screen. Used to show when ownership changes and read only nature depending on which users views the case. Allows option for users to take over ownership.

In research users saw and understood what the message meant and how to interact with it to perform their tasks.

.

[tomyems]

Couple of questions, how many participants did the research have?

I propose to update the Research part of the Status message component with:

Research

For an internal service, this was used at the top of the screen of a case management system to:

• show who owns the case
• whether the case is read only
• allow users to take over the case

Research showed that users understood the message and how to interact with it.

[ollybeal]

Thanks @tomyems - the research was conducted with six users of the service.

[tomyems]

As an iteration:

For an internal service, this was used at the top of the screen of a case management system to:

• show who owns the case
• whether the case is read only
• allow users to take over the case

(Show example as a story, so with the HTML and React code for people to re-use)

Research with 6 users showed that users understood the message and how to interact with it.

[tomyems]

We'll also add a Contribute section like we have for the Date-time component with a link to this discussion.

[tomyems]

The proposal is something like this https://62f3df93fa4c5d0d2b9cd63e--hods.netlify.app/components?name=Status%20message

(To see full set of changes see: #444)

[tomyems]

@ollybeal - your example is actually quite hard to replicate in the component, and shows that we might need to update and improve the component that we have :)

[tomyems]

From a content 2i, added verb 'show' to make the bullets consistent. So it now looks like:

For an internal service, this was used at the top of the screen of a case management system to:

• show who owns the case
• show whether the case is read only
• allow users to take over the case
  (Show example as a story, so with the HTML and React code for people to re-use)

Research with 6 users showed that users understood the message and how to interact with it.

[Sarraounia]

@tomyems couple of comments from me about the content.

1. The lead-in line read to me like it describes the service twice currently. How about the below?

For an internal case management service, this was used at the top of the screen to:

2. In the second bullet point, replace 'whether' with 'if' for simplicity.

show if the case is read only

Also, had a thought if we need a 'Writing for this component' section for some recommendations around what content goes into status messages in different scenarios? Might be one to pick up separately though!

[tomyems]

Ah my mistake, forgot to update this thread. This is the latest version: https://62f4c6a6324ac21a19b7d268--hods.netlify.app/components?name=Status%20message.

I'll change the 'whether' to 'if', and after a conversation with Sarah on Slack, have described the system in a slightly different way:

For an service to assess border risk, this was used at the top of the screen to:

(just spotted the incorrect 'an')

[tomyems]

And yes it probably should have a writing for this component section as well :)

[Sarraounia]

All sounds good - thanks @tomyems

[tomyems]

Updated 'whether' to 'if': https://6304ccddfb22d77dee029268--hods.netlify.app/components

[tomyems]

@ollybeal This research example is now published on the Home Office design system: https://design.homeoffice.gov.uk/components?name=Status%20message. - Thanks for contributing :)

[tomyems]

Proposal to add some guidance for writing status messages - improvements and suggestions welcome:

Writing for this component

The status message should be as concise as possible. The bold part and button should be short, 1 or 2 words.

If text in the middle is necessary, then ideally 1 line. It does not need to be in full sentences and does not need to end in a full stop. It should be plain text with no formatting.

Any buttons should be verbs.

Do not use links, they do not contrast well with the background, use buttons instead.

If it’s about people, make sure your content is dynamic and personalised. Use ‘person’ when it’s about one person and ‘people’ for more than one and include names if you can.

[tomyems]

Proposing to take to to the working group next Friday, 21 October. If you could provide comments by then.

When to use this component

Use status messages to:

• notify the user of a change
• tell the user something important
• inform the user that they need to do something

They are like alerts but are primarily used for internal services and can include actions for users to take. For less prominent status indicators you could use tags.

Limit to important information, or when it’s changed. Overuse risks the message getting lost.

Writing for this component

The status message should be as concise as possible and relate to the whole page. The bold part and button should be short, 1 or 2 words.

Any buttons should be verbs.

If text in the middle is necessary, then ideally 1 line. It does not need to be in full sentences and does not need to end in a full stop. It should be plain text with no formatting.

Do not use links, they do not contrast well with the background, use buttons instead.

If it’s about people, make sure your content is dynamic and personalised. Use ‘person’ when it’s about one person and ‘people’ for more than one and include names if you can.

[tomyems]

View a draft: https://63524eaf8f87b55bd6bc4f67--hods.netlify.app/components?name=Status%20message

[tomyems]

Reviewed by design system working group. To do:

• clarify 'make sure your content is dynamic and personalised' to mean include person's name in the status message.

[tomyems]

Updated to allow design as described https://design.homeoffice.gov.uk/components?name=Status%20message with 2 lines of text.

[benjystanton]

Would it be possible to enable flex-wrap on the links please? This would allow the links to wrap over multiple lines when there is not enough horizontal space.

Lack of horizontal space can be caused…

• if the viewer is using a medium viewort (but still wide enough to display the desktop layout)
• if multiple buttons are added
• if longer text is used

Screenshot of problem

Screenshot of suggested solution

[willrichards]

@benjystanton we discussed this today at the design system working group. If we can put a pull request together, we can get it reviewed by the development team and hopefully added. Happy to support with this.

[daniel-ac-martin]

(For posterity.)

This seems more likely with 3 or more buttons.

Placing flex-wrap: wrap on the flex container (the <ul>) stops the issue as presented, but does prevent wrapping within the button text. i.e. Taller buttons.

It's not currently obvious to me why the <ul> is overflowing in the first place. (Maybe we can just prevent that?)

I wonder if there might be a better solution. e.g. Should we be using a 'button group' instead? (And would it solve the problem if we did.)

[daniel-ac-martin]

Update: A button group does seem to fix this. I'm not exactly sure how. (Perhaps by preventing the overflow of the container?)

[daniel-ac-martin]

See: #572

[benjystanton]

Thanks both, I'll have a play with button group in my prototype too.

[benjystanton]

Button group looks like it does the trick, thanks. But, in my original example above, I also reduced the margin on the links themselves. Otherwise when the list begins to wrap the gap between the lines gets quite big. See screenshot. Just mentioning in case we can address this at the same time.

[benjystanton]

Adjusting the margin to something like the following helps (although there may be better ways to achieve this).

.hods-status-message__actions__link {
  margin-top: 4px;
  margin-bottom: 4px;
  }

[andymarshall-35]

Where we're using display: flex; we can also use gap: 10px 5px; to apply space around the flex element's contained buttons - gap works a lot neater than margin, as it only applies itself when it needs it to space the buttons from other neighbouring buttons (unlike margin that is always applied to the button, even if there are no other buttons to push away from, leading to other inconsistencies).

[benjystanton]

Thanks Andy, I didn't know this!

[daniel-ac-martin]

Suggested fix is here: #574

It does change some of the vertical spacing though, so it's worth someone reviewing the visual changes in Chromatic.

You'll need to use your browser's dev tools to add in some extra buttons and then narrow your browser width to see the original issue.

[benjystanton]

We discussed this component at the Design System Working Group today.

We think the open pull request is ready to go #574

A question was raised over the accessibility of the component in general. I'll email the HO accessibility assurance team and ask them to add a review of the component to their backlog. It looks as if the semantics could be improved at least. For eaxmple, the component has what looks like a heading, but it's just a div.

[knajdek]

We reviewed accessibility of the component and found the following issues:

Use of white text and the blue background attracts sighted users’ attention and conveys importance of the message. This is not communicated to screen reader users via semantic markup.

In addition, relationship between information within the status message is communicated via use of bold text and normal size text, this is also not communicated to screen reader users.

Bold text within status message should be marked up as a heading as it looks like one. This will help screen reader users easily navigate to the status message and understand all information within it.

In addition, if the status message dynamically appears on the page, for example as a result of user action, this also needs to be announced to screen reader users. Consider using ARIA live region for this.

Focus indicator on buttons might be difficult to see for users with colour vision deficiency. It relies on colour change from white to yellow and a very subtle change to the border appearance that is very easy to miss.

[benjystanton]

Thanks! As mentioned I'd be happy to have a go at improving my team's prototype to include some of these accessibility improvements, then I could bring that back to the working group to check it meets the criteria.

[benjystanton]

I've started tinkering with some of @knajdek's (and other's) feedback on the status message banner to try and improve accessibility. Just working on my team's private prototype for now.

Here's a a screenshot for context (although I'm not proposing any visual changes).

Done…

• Change main status text ("Needs review") from div to h2
• Removed extra div that wrapped the "Needs review" and 3 lines of text (don't think it was needed?)
• Add role="status" aria-live="polite" to main container
• Add hods-date-time component to review date
• Changed the 3 lines of a text from a single <p> with <br>s to a <dl>

Code…

<div class="hods-status-message" role="status" aria-live="polite">
            <h2 class="hods-status-message__status">Needs review</h2>
            <div class="hods-status-message__extra">
                <dl>
                    <div>
                        <dt>Assigned to </dt>
                        <dd>North Team</dd>
                    </div>
                    <div>
                        <dt>Claimed by </dt>
                        <dd>Kelvin Phillips</dd>
                    </div>
                    <div>
                        <dt>Review by </dt>
                        <dd><time class="hods-date-time" datetime="2024-08-31T19:00:00.000Z">31 August 2024, 19:00</time></dd>
                    </div>
                </dl>
            </div>
            <ul class="hods-status-message__actions">
                <li class="hods-status-message__actions__item hods-status-message__actions__item--active"><a class="hods-status-message__actions__link" href="#">Edit task</a></li>
                <li class="hods-status-message__actions__item hods-status-message__actions__item--active"><a class="hods-status-message__actions__link" href="#">Assign task</a></li>
                <li class="hods-status-message__actions__item hods-status-message__actions__item--active"><a class="hods-status-message__actions__link" href="#">Close task</a></li>
            </ul>
        </div>

Feedback welcome!

[benjystanton]

Working on some changes to the component here #607