Mathesar money display and db options #1243
Replies: 11 comments 20 replies
-
|
@pavish My idea in having the currency format selector was to offer users a way to fill out the all the formatting options for a currency, and then modify if they wanted to, however it seems that the possible combinations are limited, and your option eliminates that clutter. |
Beta Was this translation helpful? Give feedback.
-
@ghislaineguerin Yes, they'll have to do that. Similar to having to select the EURO option from the list each time, they'll have to type in these fields instead. My thought is that this is a non-frequent operation so it might be okay. I'm also onboard with having this, but I'm not sure if it is so important for the user that we have to prioritize it for the alpha. |
Beta Was this translation helpful? Give feedback.
-
These are available in the underlying DB type. We can just expose whichever we want for use via the API. I agree that precision isn't very useful for money types. |
Beta Was this translation helpful? Give feedback.
-
|
I've done some research on money formatting today and I'd like to propose design changes to the display options for both Money and Number, which differ from both the current design and from the proposals put forth by @pavish. My process is backwards, but bear with meBut I'm approaching this problem from a different direction. In 1/1 conversations, @pavish and @kgodey have both made it clear to me that our process should begin with the Figma design as the underlying source of truth upon which we make further decisions like API schema. I think that process works great in most cases. But for this case I'm not sure it's best. Here is my thought process:
Our current
|
| Formatted amount | Example locale |
|---|---|
-$123,456.70 |
af |
-US$123,456.70 |
am |
-US$ 123,456.70 |
ar |
-US$ 123.456,70 |
ar-DZ |
-$ 123,456.70 |
az |
-123.456,70 $ |
az-Cyrl |
-123456,70 щ.д. |
bg |
-1,23,456.70 US$ |
bn |
-123.456,70 USD |
ca |
-123 456,70 US$ |
cs |
-123.456,70 US$ |
da |
-$ 123.456,70 |
de-AT |
$-123'456.70 |
de-CH |
-$ 123'456.70 |
de-LI |
-123,456.70 US$ |
en-150 |
-USD 123,456.70 |
en-AU |
US$-123'456.70 |
en-CH |
-$1,23,456.70 |
en-IN |
-$ 123456.70 |
en-US-POSIX |
-US$123 456,70 |
en-ZA |
-USD 123.456,70 |
es-BO |
US$-123.456,70 |
es-CL |
-USD 123 456,70 |
es-CR |
$-123.456,70 |
es-EC |
-US$123.456,70 |
es-GQ |
USD -123.456,70 |
es-PY |
USD-123.456,70 |
es-VE |
-123 456,70 $ |
et |
-123 456,70 $US |
fr |
-123 456,70 $ US |
fr-CA |
-123 456.70 $US |
fr-CH |
-123.456,70 $US |
fr-LU |
-US$1,23,456.70 |
gu |
-123,456.70 $ |
he |
-123 456,70 USD |
hu |
USD-123'456.70 |
it-CH |
US$ -123.456,70 |
nl |
$ -123.456,70 |
nl-BQ |
-123 456$70 US$ |
pt-CV |
-$ 1,23,456.70 |
ta |
-$123.456,70 |
tr |
(There's also a currencyDisplay: 'narrowSymbol' option which cuts the list down somewhat by showing $ instead of more verbose text, but even so, there are still locales which display US$ instead of $)
Beta Was this translation helpful? Give feedback.
-
|
@seancolsen Your proposal is persuasive and I think it sounds good. If @pavish and @ghislaineguerin have no concerns, I think we should proceed with it. As far as I can see, this will entail:
Please let me know if I've missed anything. |
Beta Was this translation helpful? Give feedback.
-
|
Correct. I've been pondering on the UX a bit and will figure out a way to communicate some of my ideas if I have time. |
Beta Was this translation helpful? Give feedback.
-
|
For currency (arguably the more difficult UI to implement), I'm thinking of something like this:
|
Beta Was this translation helpful? Give feedback.
-
|
@seancolsen I like the existing "format" from the number Figma design more than the "formatting locale" and "custom locale" in your example. It's easier to tell what the output formatting will be and it doesn't expect users to know what "locale" means. Is there a technical advantage to your design that I'm missing? |
Beta Was this translation helpful? Give feedback.
-
|
@seancolsen I've responded here: #1243 (comment) I'm sticking with my initial suggestion, as I think it is feasible and user friendly, unless you could convince me with the advantages in your approach considering the points I've mentioned in the linked comment. |
Beta Was this translation helpful? Give feedback.
-
|
I like that your proposal for the API takes into account and is backed by the limitations of
Considering we will need to allow the user to enter the symbol while editing a money cell, do you see any advantage in asking for a currency code instead of a symbol? |
Beta Was this translation helpful? Give feedback.
-
|
@pavish if I'm understanding your proposal correctly, we would only use |
Beta Was this translation helpful? Give feedback.
-
|
@kgodey Yes, that's correct. |
Beta Was this translation helpful? Give feedback.
-
I completely agree. As I mentioned in a different thread, no user wants to figure out which locale will give them the currency symbol they want (if indeed their chosen symbol is associated with a locale at all). In general, I think 'locale' is the wrong way to think about user choices for currency or number formatting. Locale is a useful tool when we don't want to bother the user with formatting, and just want it to look 'right', or when we're trying to infer what number might be represented by a given input string. In the display use case, the user should be empowered to make it look the way they want, and I don't think choosing a locale is the most convenient interface for that. Is there a locale that uses parentheses for negation? As I mentioned in the other thread, that's quite common for accounting, and will be an option expected by anyone from that world. While we could add that as a separate one-off option, it demonstrates (to me) the folly of making users choose their number format by choosing a locale. What if there's some combination of commas, periods, negation placements, and currency symbol placements that isn't associated with any locale, or at least isn't associated with one the user knows about? Should the user try to google for a locale with their preferred format? |
Beta Was this translation helpful? Give feedback.
-
I agree with this. I think the accounting example makes a lot of sense. In most of the examples I've researched, custom number formatting was used for this purpose. |
Beta Was this translation helpful? Give feedback.
-
|
After reading through everyone's responses, here are some general thoughts:
|
Beta Was this translation helpful? Give feedback.
-
|
I agree with all the points listed by @kgodey.
{
"US Dollars": {
"locale": "en-us",
"currency_symbol": "$"
}
} |
Beta Was this translation helpful? Give feedback.
-
Having a currency list along with the accepted format for that currency is a great convenience feature I would love to have. Some of the usecases in addition to points @kgodey mentioned
To conclude
|
Beta Was this translation helpful? Give feedback.
-
Responses to concerns with my proposal"Worrying about locale"@pavish said:
@kgodey said:
I agree with all that. What if we removed the ability for users to configure the locale for Number and Money types? I don't see a need for it. Without the Non-ISO currencies@pavish said:
This is a good point. The ISO 4217 data does not include crypto currencies. As such, my approach does not handle this use-case. Here's how I'd like to handle that use-case -- and other use-cases too...
Data entry@pavish said:
Yeah I have thought about this, and I don't see any problems here.
Performance@pavish said:
I'm really surprised you're worried about performance here. What kind of performance?
Accounting notation@mathemancer said:
My concerns with other proposalsComplexity of configuring display pattern@pavish said:
That's likely to appear unconventional to users in some locales.
Okay. That addresses my above concern -- but it raises a new one which is that users are likely to expect a variety of different patterns based on the conventions of their locale. From the data under "show table" in my original comment, I can identify the following patterns that users may expect for currency display:
My source data for these patterns uses only one currency code. If we take other codes into account, then it's possible (though I'd guess unlikely) that even more patterns exist. @mathemancer said:
With the above patterns in-mind, how do you propose giving users the ability to choose from these patterns? Is this an additional dropdown? How do the options within that dropdown appear? What is its default value? Or do we expand upon the formatting dropdown options already present for Number? Keep in mind that each of the five options above has a number in it. Since we identified six ways of formatting numbers, there are potentially 30 options to present if we combine them into one dropdown (though with analysis, we could eliminate non-existent combinations).
If we add this additional configurability, doesn't that require users to worry about locale more than necessary? I think in the vast majority of cases (all??) users should not be configuring any locale-related settings on their columns. They should instead keep the locale empty, relying on the browser locale. Collaboration across localesConsider two users from different locales working on the same data. During discussions leading up to the Number display and entry specs, we agreed that for this use case it's worth it to rely on the browser locale to format numbers because that allows the formatting to vary by locale. For currency, the "display pattern" I describe above becomes an additional formatting requirement which should vary by locale. But if the user needs to configure it on a per-column basis, then it can't vary by locale. This isn't a huge problem. People would still be able to use Mathesar. But the number display might look awkward to some users. |
Beta Was this translation helpful? Give feedback.
-
|
Here's another thing to consider: When a user adds a new Money column (or converts an existing column to Money), we should set a currency for them by default. If we store the currency as an ISO 4217 code, we should pick one of the codes. If we store the currency as a symbol string, then we should pick a string. What is our process for determining the best default currency for the user? What inputs does that process have? My initial thoughts: we use the browser locale as the only input. We figure out a way to map every IETF BCP 47 language tag (e.g. I'm open to other solutions here. |
Beta Was this translation helpful? Give feedback.
-
|
Here's a dataset, there's a lot of other info in there but it does map currency codes to language tags. |
Beta Was this translation helpful? Give feedback.
-
|
This is a response to the performance of Select menu question posted by @seancolsen in #1243 (comment). I'm not responding to the entire discussion of money display options here, since I've already established my views. Any additional thoughts I have might be better discussed on the weekly call, and we could go with any option finalized on the call.
I'm talking about browser rendering performance for these 200 rows. While it is considerably less and all latest browsers are really good at handling this, I personally feel high self-resistance while rendering any more than 50 rows in a list. This stems from my earlier EmberJS days. I used to occasionally sit in on customer support calls and I've often noticed the UI I built behave unexpectedly on the customer's end. As a result, I devised a few personal rules. Some of them include:
This is just a window into my thoughts. We can go ahead and provide the list to the user in the Select menu, but eventually I'd like us to implement a virtual list for the Select menu options after the first release (low priority). |
Beta Was this translation helpful? Give feedback.
-
Research into display patternsI did some more research into different "display patterns" (as I've been calling them in this thread), and I wanted to post the results here for posterity: ResultsHere are the all the different display patterns, along with the number of locales using each pattern:
Take-away conclusionI think we can safely offer support for options Rationale:
|
Beta Was this translation helpful? Give feedback.
-
|
We discussed this during our meeting today. People present: @seancolsen @pavish @ghislaineguerin @silentninja @mathemancer Below are the specs we came up with during the meeting (with some smaller details filled in by me). SpecsSchemaThe display options schema for Number and Money are as follows: /**
* This common for both Number and Money types
*/
interface FormattedNumberDisplayOptions {
/**
* | value | example locale | example format |
* | --------- | -------------- | -------------- |
* | 'english' | 'en' | '-123,456.7' |
* | 'german' | 'de' | '-123.456,7' |
* | 'french' | 'fr' | '-123 456,7' |
* | 'hindi' | 'hi' | '-1,23,456.7' |
* | 'swiss' | 'de-CH' | '-123'456.7' |
*
* When `null`, the browser's locale will be used.
*/
number_format: 'english' | 'german' | 'french' | 'hindi' | 'swiss' | null;
/**
* PLANNED FOR FUTURE IMPLEMENTATION POST-ALPHA.
*
* - "true": display grouping separators even if the locale prefers otherwise.
* - "false": do not display grouping separators.
* - "auto": display grouping separators based on the locale preference, which
* may also be dependent on the currency"
*/
use_grouping: 'true' | 'false' | 'auto';
}
interface NumberDisplayOptions extends FormattedNumberDisplayOptions {
show_as_percentage: boolean;
}
interface MoneyDisplayOptions extends FormattedNumberDisplayOptions {
/**
* e.g. "$"
*/
currency_symbol: string;
/**
* | value | formatting pattern |
* | ---------------- | -------------------------------------------- |
* | 'after-minus' | {minus_sign}{currency_symbol}{number} |
* | 'end-with-space' | {minus_sign}{number}{space}{currency_symbol} |
*/
currency_symbol_location: 'after-minus' | 'end-with-space';
/**
* PLANNED FOR FUTURE IMPLEMENTATION POST-ALPHA.
*/
use_accounting_notation: boolean;
}Bare-minimum UX for alpha
Additional UX nicety to consider (for now or later)
|
Beta Was this translation helpful? Give feedback.
-
We could. But during the call there was a general sentiment against the approach of using actual locale values here. We didn't delve deeply into the rationale because it seemed that we all agreed on the approach of use more generic values. Here's my rationale for using generic values like "english" instead of actual locale values like "en": When we ask the user to select one of these 5 choices, we're not asking them to select an actual locale like 'en'. Instead we're asking them to select one of 5 locale categories that we have invented. The choice of 'swiss', maps to the locales "de-CH", "de-LI", "en-CH", and "it-CH". The choice of 'english' maps to 508 different locales, one of which is 'en'. I feel that storing the category (as we have invented) more accurately represents the data that we're acquiring from the user.
I'm not sure what back end work needs to be done. @silentninja or @mathemancer might have a better sense. I'm actually somewhat confused about why we need to deal with any of this on the back end. My inclination would be to store the
Implementing the list of currencies will involve a substantial amount of additional work, including UX design, API, and front end. I've been pondering on this, and I want to advocate a bit more strongly for putting this off until after alpha. Without the list of currencies, the user will still be able to configure their column for any currency. It's just a tiny bit more work. I don't think we need it right away, and I think we have more important priorities to focus on for alpha.
This seems good. I will create those tickets. |
Beta Was this translation helpful? Give feedback.
-
Sounds good, thanks for the explanation.
Knowing which display options go with which types allow the backend to invalidate (remove) display options when the type of a column is changed outside Mathesar. I think it makes sense for @silentninja to create the backend tickets, though. @ghislaineguerin can you create a design ticket and update the design?
Okay, that's fine to put it off until after alpha, I thought speccing it out would not be much work because you had said:
|
Beta Was this translation helpful? Give feedback.
-
|
@kgodey Yeah, it won't be too much more work to finish producing that data set that we'd use for the currency types API. But that's just one piece of the puzzle. I'll figure out how to wrap up the work that I've done on it so that it's easy to pick up later on. And I'll write the tickets for the work of supporting a currency list. |
Beta Was this translation helpful? Give feedback.
-
For the sake of speeding things along, I'll mention that I don't actually need any additional design work to complete the front end Money implementation (now that we've simplified it a bit). We'll need additional design work for the currency type selector (and I'll make a ticket for that). But if we want to save time and move faster we could avoid having Ghislaine spend more time on this. |
Beta Was this translation helpful? Give feedback.
-
|
@seancolsen If you don't need the design work, let's not do it. :) |
Beta Was this translation helpful? Give feedback.
-
I'd like to continue the conversation from the Matrix channels regarding Mathesar money display options here. I have a few suggestions which affect the UX.
Display options
Here's the new design I'm proposing for Display options for Mathesar money:
Refer the figma link for the current spec.
Intlon the frontend.Database options
scaleandprecision, which are present for Numeric.scaleas database option for Mathesar Money.Reference Links
Beta Was this translation helpful? Give feedback.
All reactions