Inline Text
Guidelines
Inline text communicates messages in an non-blocking way. It’s displayed inline and doesn’t block any other part of the interface.
Usage
- Visual: Camouflaged–Visible
- Voice & Tone: (Varies per circumstance)
- Motion: Static
- Duration: Permanent
- Audio: Muted
Inline text can be more hidden or visible (depending on the context), but it’s always displayed inline, inside a UI component or next to another UI component. The text should blend with the surrounding UI, except for error states.
Inline text can show one of the following states:
- Empty: when data is absent or unavailable.
- Error: when the system cannot load content, or when a form field is problematic.
- Informational: when an item has an atypical status, e.g. duplicates.
- Transient: when the system is processing an action, e.g. saving, loading, sending email, etc.
For an empty state that affects the whole page, consider using Inline Text + Illustration.
For form error, the message is displayed in red and typically used in conjunction with a popover.
Inline Text in Context
Inline text can appear in many different contexts. Refer to the variants sections below to see the different examples.
Dos and Don’ts
Do
- Do keep it short. 1–2 sentences is sufficient for most use cases.
- Do use a different color when displaying error messages.
Do not
- Do not depend on inline text if the message is more urgent, e.g. warn when user is about to delete a record.
- Do not visually differentiate inline text too much from the surrounding UI. Avoid significant changes, e.g. bigger font size, inverted background colors, etc. At most, the text should change color (for errors).
- Do not use animation/motion to display inline text. At most, it should fade in/out for transient states.
Variants - Component
Variants - State
It looks as if duplicates exist for this lead. View Duplicates.
3 of 10 files selected
Saving…
3 potential duplicates found.
Variants - Screen Size
There are no special variants for text messaging component in mobile. Just as it is in desktop, the text should adapt to the surrounding UI.
UI Text
Text can vary greatly case to case, depending on the context. The guidelines below serve as examples, but you are not limited to them.
State | Intent | Example |
---|---|---|
Empty | State a fact | No deals to show. |
Empty | Encourage use of feature / suggest something else / use a best practice | |
Informational | Show a status | |
Transient | Show the system is working on a request | |
Error | Inform that the required field is empty | |
Error | Inform that the input is not a valid value. |
Recommended Specs
Refer to this code sample for basic text markup.
In general, the messaging text should conform to the text specifications within that UI component. If it’s a component that normally doesn’t have text, treat the messaging text as regular body text.
If it’s an error, add the specs below.
Description | Token | Value |
---|---|---|
Error text color | $color-text-error | #c23934 |