Skip to content
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.

Sign up for GitHub

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

Jump to bottom

add section 2: methodology for approaching & evaluating solutions #23

Merged
merged 3 commits into from
Aug 9, 2024
Merged

add section 2: methodology for approaching & evaluating solutions #23

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
80a7802
+2 methodology for approaching & evaluating solutions
tantek Aug 6, 2024
4ce02de
simplifying edits from mt
tantek Aug 7, 2024
e04e688
100% reliable like a calculator
tantek Aug 8, 2024
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
100% reliable like a calculator 
users expect reliable unit conversions like arithmetic with a calculator
  • Loading branch information
@tantek
tantek authored Aug 8, 2024
commit e04e6885940fda8234aa64787fdc3db682c29f2e
6 changes: 5 additions & 1 deletion amount.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,4 +11,8 @@ then browsers could offer a privacy-respecting user-interface to display these a

## Methodology for approaching & evaluating solutions

Per the priority of constituencies, we should first look for solutions that users can trust (like if there is an affordance to convert units, it should be 100% reliable when present) and, second, solutions that are more dependable and robust for developers. In particular, we should look for and prefer [declarative approaches](https://www.mozilla.org/en-US/about/webvision/full/#thedeclarativeweb) over imperative approaches.
Per the priority of constituencies, we should first look for solutions that users can trust,
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.
Comment on lines +15 to +16
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member Author

@tantek tantek Aug 9, 2024 •
edited
Loading

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
Second, we should look for solutions that are minimal work, simpler, and more dependable and robust for developers.
In particular, we should look for and prefer [declarative approaches](https://www.mozilla.org/en-US/about/webvision/full/#thedeclarativeweb) over imperative approaches.