Meters are visual representations of a quantity or an achievement. Their progress is determined by user actions, rather than system actions.
By default, the meter has a blue fill to show the value. This can be used to represent a neutral or non-semantic value, such as the number of tutorials completed.
The positive variant has a green fill to show the value. This can be used to represent a positive semantic value, such as when there’s a lot of space remaining.
The notice variant has an orange fill to show the value. This can be used to warn users about a situation that may need to be addressed soon, such as when space remaining is becoming limited.
The negative variant has a red fill to show the value. This can be used to warn users about a critical situation that needs their urgent attention, such as when space remaining is becoming very limited.
Meters should always have a label. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the label could be undefined. These meters without a visible label should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”). The label is always placed above the track.
Meters can have a value label that gives detailed information about the value shown (e.g., "60%" or "2 of 8"). This value label works alongside the label and should not be displayed if the label itself is not displayed. Similar to the label, the value label is always placed above the track.
The width of a meter can be customized appropriately for its context. The default width is size-2400 (192 px on desktop and 240 px on mobile).
Meters come in 2 sizes: large and small. By default, meters are large. Use the small size when there are multiple meters shown at the same time in a more confined space, such as in tables or cards.
The value shows a quantity or an achievement, from 0 to 1, such as tutorials completed, storage space, etc. Unlike the progress bar, this value is determined by user actions, rather than system actions.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
Property | Values | Default value |
---|---|---|
variant | informative / positive / notice / negative | informative |
label | text / nothing | – |
value label | text / nothing | – |
width | number | size-2400 |
size | small / large | large |
value | number (0 to 1) | 0 |
When the label is too long for the available horizontal space, it wraps to form another line. The value is always shown in full and never wraps or truncates.
A progress bar fills automatically as the system loads either determinately or indeterminately. A user's actions do not affect the progress bar; it just indicates how long they must wait for the process to finish.
A meter indicates how much the user has completed or how far they are in a continuum.
Use the built-in style for showing a label associated with the meter. This style always has a left aligned label and an optional right aligned value above the track. The label should be in sentence case.
When a stack of meters appears in a table, the label can also be in the form of a table column header.
Meter variants can be used to represent semantic values by switching variants as the value changes, from positive, to notice, and then to negative. This kind of variant switching should be handled appropriately within the context of your product so that you’re setting accurate expectations for your users about the semantic meaning.
For RTL (right-to-left) languages, the layout of the meter is mirrored. The label is right-aligned, the value is left-aligned, and the fill progresses from right to left. Beware that the placement of the percent sign differs depending on the locale.
A theme is an intentional, systematic customization of Spectrum. It has unique visual attributes. For more information, view Theming.
Meters remain the same across themes.
Date | Number | Notes |
---|---|---|
Apr 06, 2022 | 7.0.0 |
|
Feb 17, 2022 | 6.1.0 |
|
Jul 20, 2020 | 6.0.0 |
|
Aug 22, 2019 | 5.1.0 |
|
Apr 20, 2019 | 5.0.0 |
|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
Component is included in the Spectrum for Adobe XD plugin.