You shouldn't use ns-highlighter for that
This is the story of a name gone wrong.
When a conversation to solve a problem for the customer begins, the design system team listen intently and contribute wholeheartedly.
Until very recently, we kept hearing a similar thing on a lot of our Design System drop-in sessions, or more exactly, we kept saying the same thing regularly: "you shouldn't use the ns-highlighter
component for that, consider this instead".
But before we get into why this kept happening, let's introduce you to the component.
What's a highlighter in Nucleus?
ns-highlighter
is a component that will communicate important information, a warning, an error, or a success message, usually time sensitive and following an action from the user.
The component has been built with accessibility in mind, and its content will be read by a screen reader when the page loads or when it's added to the page after an action by using the role="alert"
And this is where things go wrong. Here is what (the Mozilla Developer Network says about this ARIA role here):
"Because of its intrusive nature, the alert role must be used sparingly and only in situations where the user's immediate attention is required."
We should've foreseen what comes next, but we didn't.
The confusion
The component has been used for how it looks, rather than how it works. Because it comes with a colourful accent and an icon, it was the perfect choice to make something stand out from the rest of a page, like a phone number, or some supporting information that isn't key but worth highlighting to the user.
But by using it for this purpose, the outcome would've been a page that reads out a phone number or a piece of content that isn't important or worth reading out loud on screen readers when the page loads, before anything else.
So we kept saying that "You shouldn't use the ns-highlighter
for this" in a lot of the design reviews and drop-in sessions. So much so that we joked about making a mug with the quote!
But this wasn't the designers' fault, ultimately we made a mistake.
Where did it go wrong?
We picked the wrong name for the component. While we did pick a name relevant to what the component achieves, it wasn't the right verb to use. Highlighting isn't strong enough to represent what the component does. And the designers picking this component were doing the right thing: picking ns-highlighter
to highlight a piece of information just makes sense.
The problem is that the component doesn't highlight something. It warns the user about something, it alerts, it requires their full attention because the information contained in it is important to what they are doing, or about to do.
And looking back at our story tickets, this is what we could find in the comments when it came to finding a name:
ns-windsock
ns-flag
ns-marker
ns-pennant
ns-roadsign
ns-support
ns-highlighter
Even more obvious ... our initial Request For Change ticket was called In-page alerts (this type of ticket where we capture the needs/problems to solve with a component, and all existing evidence and research available).
In retrospect, we could've named it ns-alert
, ns-flag
, or ns-roadsign
and we would probably have seen fewer misuses.
What we did about it
But we made another mistake, and that was not recognising the need for a softer highlighter. And the repeated mistakes told us the hard way that we probably needed to offer a solution to make a piece of information stand out, but more softly, without capitalising on a user's main senses when they access the page or take an action.
And this time we learned our lesson and picked a name that will hopefully be less confusing: ns-standout
.
We are also considering renaming ns-highlighter
to ns-alert
as part of a future breaking change to completely remove any confusion.
And in the future, we'll pay extra attention to the names we pick, and how they could mislead or be perceived in different ways by those using Nucleus.
Learn more about ns-highlighter
and ns-standout
in our documentation!
Related articles
Multi-branding in Nucleus
How we started enabling multi-branding in Nucleus...

Mekala Nagarajan
19 April 2022
Visual Regression Testing
How we implemented visual testing...

Praveen Asokan
1 April 2022
Vanilla first
It is a mindset, an undercurrent supporting our decision making process...

Drew Jones
18 March 2022