Use a meter for a read-only scalar value inside a meaningful known range; use a progress bar for task completion, a slider for approximate user adjustment, and a spinbutton for small exact numeric input.
Use a meter for a read-only scalar value inside a meaningful known range; use a progress bar for task completion, a slider for approximate user adjustment, and a spinbutton for small exact numeric input.
Practice the judgment: Imagine this situation: A storage meter is used as a progress bar while files upload, so users think capacity is changing because the upload is completing. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Meter | Progress bar | Slider | Spinbutton / numeric stepper |
|---|---|---|---|---|
| UI or UX | UI + UX - Read-only scalar value gauge within a known range | UI + UX - Measurable system-operation progress indicator | UI + UX - Single-value bounded range control | UI + UX - Bounded incrementable numeric-value control |
| UI guidance | Use native meter semantics or equivalent read-only meter attributes, and pair color bands with text such as Healthy, Warning, Critical, Low, Normal, High, or Over limit. | Show a labeled bar with a track, filled value, and nearby helper text that reports the measurable unit such as percent, bytes, rows, files, records, or stages. | Render one thumb on a track with a persistent label, visible current value, unit, min and max labels, focus state, and disabled or read-only state. | Render a visible label, editable numeric value, unit, lower and upper bounds, plus and minus controls, focus state, and warning, error, disabled, and read-only states. |
| UX guidance | Explain whether higher, lower, or middle values are better, what threshold the current value crosses, and what action is available when the meter enters a warning or critical range. | Use a progress bar when the system can honestly report movement toward a known finish and users need to decide whether to wait, cancel, retry, continue elsewhere, or return later. | Help users adjust one bounded value quickly when the relative position or intensity matters. | Use a spinbutton when users adjust a small count or bounded quantity by one or a few steps and still may need to type the exact number. |
| Good UI | An account storage card says 86 GB of 100 GB used, marks 70 GB as warning and 90 GB as critical, and labels the current state Critical. | A document upload card says Uploading evidence.zip, shows 64%, 32 of 50 MB, a Cancel action, and keeps the rest of the form usable. | A Brightness slider shows 55%, dim and bright endpoint labels, visible focus, and a paired number input. | A Guests control shows label, value 2, minus and plus buttons, range 0 to 9, and a clear unit beside the field. |
| Bad UI | A progress bar for uploading evidence.zip is implemented as a meter, so task completion and capacity status are confused. | A progress bar reads 100% complete while virus scanning and server acceptance are still pending. | A two-stop slider is styled like a switch but lacks on/off semantics. | An account ID field has plus and minus buttons, implying the identifier can be stepped. |
| Good UX | A user sees storage at 86 of 100 GB, understands the account is in the critical band, opens Manage storage, and deletes old exports before uploads are blocked. | A user uploads evidence.zip, sees progress move from 12% to 64%, cancels before commit, retries after a network error, and gets a completed receipt only after server processing succeeds. | A user adjusts brightness with arrow keys, types 65 in the number field, sees both controls synchronize, and gets a warning near battery-heavy values. | A user enters -3 for guests, the value is repaired to 0, and the interface explains the lower bound before submit. |
| Bad UX | Users mistake quota level for upload completion because the meter animates like progress. | Users leave after 100% transfer even though server processing later rejects the file. | A user is asked to choose Small, Medium, or Large through a numeric rail with hidden labels. | A user scrolls a page while an account number field is focused and accidentally changes the stored account ID. |
| Best fit | A current value exists inside a meaningful known range. | A system operation has a measurable total or bounded progress value. | Users adjust one bounded value such as brightness, volume, opacity, zoom, intensity, cost tolerance, or preference strength. | Users adjust a small bounded count such as guests, copies, items, seats, nights, minutes, retries, or quantity. |
| Avoid when | The value represents task completion or loading progress. | The wait is short and only needs scoped activity feedback. | Users need to enter an exact, arbitrary, or high-stakes number. | The value is a numeric-looking identifier, code, account number, card number, phone number, postal code, date, or formatted string. |
| Required state | Normal state inside the acceptable band. | Idle state before the operation starts. | Initial value state with visible label, min, max, current value, and unit. | Initial state with visible label, default value, unit, min, max, and step. |
| Accessibility burden | Prefer the native meter element where possible because it carries the correct read-only meter semantics. | Provide an accessible name that identifies the operation and affected object. | Prefer native range input where possible. | Expose the editable value as a spinbutton or native number input with a visible label. |
| Common misuse | Using a meter to show task progress such as upload completion. | Fabricating progress values just to make users feel movement. | Using a slider for a binary on/off choice. | Using a spinbutton for numeric-looking identifiers or codes. |