Meter

Problem Context

• The product can name the measured object and provide a current numeric value inside a meaningful range.
• The value represents state such as storage used, battery charge, quota consumed, memory utilization, credit utilization, score, risk, capacity, or health.
• Users need to compare the current value against low, high, optimum, warning, critical, limit, target, or safe bands.
• The value is not directly editable in this context, though an adjacent action may help users improve the state.

Selection Rules

• Choose meter when a read-only scalar value has a meaningful minimum and maximum.
• Use a native meter element when possible for web surfaces, with value, min, max, low, high, and optimum when threshold bands are meaningful.
• Use visible value text such as 86 GB of 100 GB used when a percent alone does not explain the measurement.
• Label whether higher, lower, or middle values are better whenever the direction is not obvious.
• Use progress bar when the value represents completion of an active task that moves toward a finish.
• Use slider when users change the value by dragging or keyboard adjustment.
• Use spinbutton when users type or step an exact numeric value.
• Use ordinary text, stat cards, tables, or charts when the value lacks a meaningful maximum.
• Do not use a meter for identifiers, one-off counts, dates, rankings, or cumulative totals with no bounded scale.
• Do not rely on browser default color alone; add text or icon status for threshold meaning.

Required States

• Normal state inside the acceptable band.
• Warning state near a threshold users can act on.
• Critical or over-limit state with an action or consequence.
• Low-better state where the optimum range is near the minimum.
• High-better state where the optimum range is near the maximum.
• Middle-better state where both extremes are less desirable.
• Unknown or unavailable measurement state that removes the meter instead of showing a fake value.
• Loading or refreshing state before a current value is known, using progress or loading semantics instead of meter.

Interaction Contract

• The meter is read-only; users cannot drag, type, increment, or submit the meter itself.
• The visible label identifies the measured object and the value text includes the unit and total range.
• Threshold labels explain the consequence of low, high, optimum, warning, critical, and over-limit bands.
• If the value updates automatically, the product announces meaningful threshold crossings rather than every small change.
• A crossed warning or critical threshold offers an adjacent action such as Manage storage, Turn on power saver, Reduce risk, or View details.
• If max, min, unit, or current value is unknown, the product uses unavailable or loading state rather than a misleading gauge.
• The meter does not replace validation, progress, input, or chart patterns when those better match the task.

Implementation Checklist

• Define the measured object, unit, current value source, minimum, maximum, threshold bands, optimum direction, update frequency, and actions before choosing a meter.
• Use native meter when browser support and styling needs allow; otherwise recreate role, accessible name, current value, minimum, maximum, and useful value text.
• Keep text outside the meter track so labels and values remain readable at any fill amount.
• Pair color bands with text, icons, or labels; ensure low/high/critical meanings are available without color.
• Use aria-valuetext or native fallback text for values where a percent is not enough.
• Test low, normal, high, optimum, over-limit, unavailable, and refreshed-value states.
• Avoid interactive affordances such as thumbs, handles, plus/minus buttons, and editable text inside the meter.

Common Generated-UI Mistakes

• Using a meter to show task progress such as upload completion.
• Using a meter for a value without a meaningful maximum.
• Showing percent without unit, total, or threshold meaning.
• Using color alone for warning and critical ranges.
• Making a read-only meter look draggable or editable.
• Failing to explain whether high, low, or middle values are best.
• Putting headings or important controls inside a custom meter element where descendants may be presentational.

Critique Questions

• What object is being measured, and what are the minimum and maximum?
• Is the value read-only in this context, or should this be an input control?
• Does the value represent current state or completion of a task?
• What unit and value text will users hear and see?
• Which thresholds matter, and what action should users take at each band?
• Is high, low, or middle the optimum range, and is that clear without color?