Version 6.0.0

Meter

Meters are visual representations of a quantity or an achievement. Their progress is determined by user actions, rather than system actions.

Anatomy#


Image illustrating through labels the component parts of a standard meter, including its value, fill, track, and label.

Options#


Key example of 2 meters in positive variant. First meter label Tutorials completed, 2 of 8. Second meter label Storage space, 15%.

Positive variant#

By default, the meter 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, or a non-semantic value, such as the number of tutorials completed.

Key example of a meter in notice variant. Label Storage space, 80%.

Notice variant#

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.

Key example of a meter in negative variant. Label Storage space, 90%.

Negative variant#

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.

Key example showing how to label a meter. Label Tutorials completed. Label is positioned above the meter track and aligned to the left.

Label#

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.

Key example showing a meter value. Label 2 of 8. Label is positioned above the meter track and aligned to the right.

Value label#

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.

Key example of 2 meters in positive variant at 2 different widths. Both labeled Tutorials completed, 2 of 8.

Width#

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).

Key example of 2 meters in positive variant in large and small sizes. Both labeled Tutorials completed, 2 of 8.

Size#

Meters come in 2 sizes: large and small. By default, meters are large. The small size is used when there are multiple meters shown at the same time in a more confined space (e.g., tables, cards, etc), otherwise the large size should be used.

Key example of 2 meters in positive variant showing 2 different values. First meter value 0.25, label Tutorials completed, 2 of 8. Second meter value 1.00, label Tutorials completed, 8 of 8.

Value#

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.

Table of options#

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.

PropertyValuesDefault Value
variant
positive / notice / negative
positive
label
text / nothing
value label
text / nothing
width
number
size-2400
size
small / large
large
value
number (0 to 1)
0

Behaviors#


Key example of a meter showing text overflow. Meter label Tutorials abgeschlossen, 1 of 4. New line created for second word abgeschlossen.

Text overflow#

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.

Usage guidelines#


Progress bar or meter?#

A progress bar fills automatically as the system loads 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.

Key example showing correct usage of meter. A bar loader and meter. Bar loader label Loading data, 80%. Meter label Tasks completed, 1 of 5.

Labels#

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.

Key example showing correct usage of meter. Meter label Tasks completed, 1 of 5.

Representing semantic values#

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.

Key example of 3 meters in 3 variants. First meter, positive variant, label storage space, 26%. Second meter, notice variant, label Storage space, 80%. Third meter, negative variant, label Storage space, 90%.

Internationalization#


Key example of meter internationalization for right-to-left languages. Layout of meter is mirrored, label in Arabic Storage space 26%.

RTL#

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.

Changelog#


DateNumberNotes
Jul 20, 20206.0.0
  • Renamed "warning" variant to "notice"
  • Rename "critical" variant to "negative"
  • Added value and value label options
  • Added width option
Aug 22, 20195.1.0
  • Added text overflow behavior
Apr 20, 20195.0.0
  • This component is now individually versioned (individual versions of existing components start at 5.0.0)
  • Added RTL (right-to-left) guidelines

Design checklist#


N/A

All interactive states

Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).

Multiple options

Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)

All color themes

Works properly across all four color themes (lightest, light, dark, darkest).

All platform scales

Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).

Defined behaviors

Includes guidelines for layout (wrapping, truncation, overflow), animation, interactions, etc.

Usage guidelines

Includes a list of dos and don’ts that highlight best practices and common mistakes.

Accessible contrast

Follows WCAG 2.0 standards for contrast (AA).

Internationalization guidelines

Works properly across various locales and includes guidelines for bi-directionality (RTL).

N/A

Keyboard interactions

Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.

Design tokens

All design attributes (color, typography, layout, animation, etc.) are included in Spectrum DNA.

Generated UI kit

Includes a downloadable XD file that has been generated by code and shows multiple variations, states, color themes, and scales.

In Spectrum for Adobe XD plugin

Component is included in the Spectrum for Adobe XD plugin.