New Component: Meter

[macandcheese]

Description

A consistently formatted and styled meter component that leverages the native meter element.

User Stories

Consistently display data limits, quotas, disc space, etc.

Can also be useful for item completeness, profile "filled out" progression messaging, etc.

Helpful Details

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter

Adobe Spectrum's implementation: https://spectrum.adobe.com/page/meter/#Anatomy

They don't seem to leverage the native "levels" that are associated with color, but they DO have consistently placed and formatted descriptive and value text areas.

• Ensure it works both with / without the "step" attributes (always one color OR stepped color based on those "steps")

Online "item completeness":

Enterprise Manager :

[bstifle]

gonna jump on this design this week

[paulcpederson]

Here's a couple other versions of this UI from Online:

[bstifle]

Edited - Aug 2023 to hide outdated designs.

[bstifle]

Leaving discussion open for this until next Wednesday 6/16

[bstifle]

Alrighty! Moving this one over to developer hands for a future sprint

[driskull]

@jcfranco @julio8a I think new components need to go through an API design process before being implemented.

Just looking at the designs, it's not super clear on how the API for this component should be implemented.

The native HTML meter element has the following attributes: min, max, low, high, optimum, value.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter#attributes

It seems like this component:

• Has a label that is optional but always on top. Would we be better off using a calcite-label to wrap this instead?
• Has a value, min, max, remainder, remainderLabel?, valueLabel? , maxLabel? The labels go after the value but sometimes are shown in place of the value altogether?
• Seems to be some way to position the meter above, below, or in-between the labels/values?
• low, high, optimum values are optional and render red/yellow/green.
• Seems like the color of the meter can be altered as well? Does this need a prop? or would this be a CSS var?
• Seems like there's some way to alter the appearance to be unfilled?

I think for new components we should maybe have a meeting to go over these requirements first. Its kinda tricky to decipher how the component should behave.

I'm not sure this is an issue someone can just grab and implement.

[jcfranco]

@driskull I was thinking the API would come from the implementation phase, but we could tweak this of course.

Looking closer at the existing summary and your comment, I agree with you that this needs more detail. Along with the design mockups, we should make sure the summary lists the requirements on what this component should do. For example,

The meter should: 
  * support the following display modes [...deets].
  * not be focusable.
  * not be interactive.
  * ...

Having this would help with the API design, testing and even planning if the scope is too big. We can even work on a requirements starter template to guide this part of the process.

@julio8a WDYT? Can we beef up the requirements before tackling this one in this sprint?

[driskull]

Sounds good @jcfranco. More documented requirements along with the designs should be enough if they are thorough.

[bstifle]

@jcfranco i can provide more details for this

[juliepowell]

This is a good candidate for Calcite - consistent design to be used across ArcGIS. Should it be ported from ArcGIS App Components?

[yelenakreyndel]

A design task to create a component is assigned to @macandcheese using this issue. Design work needs to be complete for May release for us to implement this component in September. I recommend renaming this component to Progress Indicator or Progress to align with industry standard. @macandcheese, I left some comments for you in the description.
Cc'ing @jcfranco @geospatialem

[macandcheese]

I recommend renaming this component to Progress Indicator or Progress to align with industry standard.

Some questions to clarify here...

We already have a progress component that replicates the native progress element. This issue is to add a new meter component to replicate the native meter element. The two native elements have different use cases and configuration options. Additionally the existing arcGIS component is arcgis-meter.

Adobe's Spectrum has a nice succinct use case distinction between their versions: https://spectrum.adobe.com/page/meter/#Progress-bar-or-meter?

[macandcheese]

Adam, please let us know what design work is needed and how would it be different from what Bryan already provided.

I'll be sending out a survey post dev-summit. The way our labels work has changed since this initial design work so will update that and reconcile any other changes in requirements that surface from survey. But I imagine it won't be drastically different in appearance.

Adam, will this work be designed in Figma or prototyped or both?

Likely both, the API for this should follow the native meter element closely. cc @jcfranco

[geospatialem]

Updating design work to the June milestone.

[github-actions]

Installed and assigned for verification.

[geospatialem]

Verified on the main branch with the following properties:

• appearance
• fillType
• groupSeparator
• high
• label
• labelType
• low
• max
• messageOverrides
• min
• numberingSystem
• rangeLabels
• scale
• unitLabel
• value
• valueLabel

cc @ashetland @SkyeSeitz for Figma UI kit additions.