-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add section 2: methodology for approaching & evaluating solutions #23
Conversation
Add a draft section 2, methodology for approaching & evaluating solutions
Incorporate simplifying suggested changes from mt Co-authored-by: Martin Thomson <mt@lowentropy.net>
Would it make sense to look at deployed experience in the form of custom elements? Similar to how we'd look at user experience with https://github.com/github/relative-time-element and friends when evaluating this sort of proposal around time. |
Yes, as part of the next section, "3. prior/existing features (if any) and existing proposals (if any) that attempt to solve the problem(s)" as noted in https://github.com/mozilla/explainers/?tab=readme-ov-file#explainer-sections. I'll be writing that up next as a separate PR. Also thanks for the link to relative-time-element, going to use that as part of another Explainer I'm working on for expanding the |
users expect reliable unit conversions like arithmetic with a calculator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This raises a question for me. Is "amount" a count or is it a metric? As named, it strongly implies a count.
An amount is counting and that doesn't need units. Displaying a count might involve localization "10,000" vs. "10.000" or even abbreviation "10k". The range of options is limited.
A metric is a number, which can include negatives (-10°F) and fractional or decimal parts. That has the same localization concerns apply, but the catch is that there are now units to consider, which makes it far more substantive an effort to define and implement.
e.g. if a solution enables an affordance to convert units, it should be 100% reliable like a calculator, | ||
as users will expect any unit conversions to be simple arithmetic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might pay to note that currency conversions do not meet this standard because they are subjective or changing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I just realized that the currency thing makes this far more interesting than before if you think about the presentation of counts vs. metrics. Currency amounts are a count not a metric.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do not meet this standard because they are subjective or changing
This brings up a meta-point, which is where to document what is deliberately "out of scope" for an Explainer.
I think section "8. caveats, shortcomings, and other drawbacks of design choices, both current and any prior iterations" is suitable for this purpose, in order to keep section 1 simpler and shorter. I'm open to alternative suggestions.
Update: captured meta-point in #25
Amounts can be unitless or have units. From a prose / common language perspective; there is overlap and no strict separation. An "amount" can be a purely numerical count (perhaps fractional) or have units, such as the "amounts of ingredients in a recipe", since recipe ingredients often have units (one does not say "metrics of ingredients in a recipe" which has zero literal quoted results in DDG and Google Search whereas the former has numerous results).
Or "1,5" vs. "1.5".
Fortunately there is plenty of prior work to build on, such as SI units and e.g. Apple OS units and measures types. |
add out of scope currencies and why (per [comment from mt](#23 (comment))), with extensibility considerations, and possibly numerical-punctuation only support
add out of scope currencies and why (per [comment from mt](#23 (comment))), with extensibility considerations, and possibly numerical-punctuation only support
Add a draft section 2, methodology for approaching & evaluating solutions