Multiple units are confusing

[tal-m]

Description In the transaction log, different transactions are given in different units. It's not clear what the relation between the units is, so the UI is confusing.

To Reproduce Steps to reproduce the behavior:

1. Receive a 3333333 smidge transaction
2. Send a 10 smidge transaction
3. View the transaction log

Expected behavior A summary of all transactions using the same coin unit (potentially with conversions to more easily readable units in parentheses)

Example

 Monthly coins: 0.003 GSMD
 SMESHED 0 SMH
 SENT 10 SMD
 RECEIVED 0.003 GSMD
 total
 --
 TOTAL SMESHED...................0 SMH
 TOTAL SENT...................10 SMD
 TOTAL RECEIVED...................0.003 GSMD

[avive]

Here's the formatting function we use to display coin amounts as strings in the app: https://github.com/spacemeshos/smapp/blob/f57af354e8c4cc5050ca6d8026ddb156c100ea15/app/infra/utils.js#L23 - call it the root of all evil :-)

The basic idea is that we avoid displaying huge numbers or very small fractions - the tradeoff here is between extremely user unfriendly numbers e.g. 0.00000000001 SMH or 3,423,423,43,242 Smidge which can't be easily rounded to short strings w/o losing information, and having multiple units. Very open to improvement ideas and an alternative formatting solution, but just using 1 or 2 units is insufficient. I think that having 4 units is the least bad option we have. Not great, but better than other alternatives.

In addition, there's simply not enough space in the current ui to display huge amounts, if we chose to display everything in Smidge or in Smesh then we'll need to redo most of the screens layout.

[avive]

@lrettig - you also had some ideas to improve this. It is not as simple as using 1 unit.

[tal-m]

How about using one unit (e.g., the largest applicable one), and using exponential notation for units that are too small? We can also add clarification in parenthesis. For example, the display above would be:

Smeshed:    0       GSMD
Sent:       1E-08   GSMD (10 SMD)
Received:   0.003   GSMD

This might actually be better in SMD, in which case it would be:

Smeshed:    0       SMD
Sent:       10      SMD 
Received:   3.33E06 SMD (0.003 GSMD)

[lrettig]

Bitcoin uses "bitcoin" and "satoshi" as its primary units (source). Ethereum uses "ether" and "wei" (source).

Notice how different these pairs of names are.

"Smesh" and "Smidge" are too similar. Their abbreviations are even more similar: SMH, SMD. This is poor UX that will lead to confusion, and to users sending many orders of magnitude more or less value than they intend.

We need ~three names that are, and sound, completely different. For everything in between, we should use standard SI prefixes (mega-, giga-, etc.).

How about using one unit (e.g., the largest applicable one), and using exponential notation for units that are too small?

This is a reasonable first order improvement to the status quo!

[tal-m]

I agree about the abbreviations. I'm not so sure about the names though, and in particular about needing more than one for common use. We get by quite well for distances with "meter" and SI prefixes, over a huge range of magnitudes.

Where do "regular" users (i.e., not programmers) ever use satoshi or wei?

[lrettig]

Everyday users denominate gas on Ethereum in "gwei" (gigawei). The situation is similar w Bitcoin fees and satoshi (the unit there is sats/byte).

[tal-m]

Ok, that makes sense. But these are different "domains" of usage. If we denominate "gas" in one unit, and everything else in the other (in terms of the UX), wouldn't this prevent users from making mistakes regardless of how the units are named?

[SS-WR]

We need 2 units.

1. Main unit Smesh works.
2. Per the secondary unit - we can indeed see now "Smesh" and "Smidge" are too similar. In addition:
3. We had a discussion in the team per the naming at large. Some team members have expressed that having too many "SM"/"SMH" sound repeating themselves doesn't work for them: one suggestion was to switch for instance "Smesher" (ie full node) with "Weaver". I think opening up the secondary name+potential other name changes to any component that isnt "Smesh" will serve the community +it's a good activity for the community to engage in (fyi changes will be for 0.2). Thoughts?

[avive]

We agreed to only open coin and app names for 0.2 - not for 0.1. There are 3 separate issues here that we need to consider independently.

1. Unit names. smesh/smidge vs something else for 0.2. We seem to agree that smidge and smesh are too similar and we need to come up with 2 differentiated names and symbols.

2. Consider something else instead of Smesher for 0.2. Should be a separate discussion. As part of the terminology. Please see our current canonical naming here: https://github.com/spacemeshos/product/blob/master/sm0.1_names.md

3. Improve amounts display in the app.

Regarding 3 - we can't use scientific notation. Scientific notation is for scientists, not for normal non-technical people. I've never seen a game with points that uses scientific notation for numbers. The user does have to deal with 2 types of amounts - very small (for tx fees) and large (in smesh units) and we definitely don't want to display very large or very small numbers unformatted - hence the giga and mega current usage and the adaptive display based on the amount itself (see above). I'm open to alternative proposals for 0.1 but they need to be more user friendly than what's currently implemented.

[tal-m]

Regarding 3 - we can't use scientific notation. Scientific notation is for scientists, not for normal non-technical people. I've never seen a game with points that uses scientific notation for numbers. The user does have to deal with 2 types of amounts - very small (for tx fees) and large (in smesh units) and we definitely don't want to display very large or very small numbers unformatted - hence the giga and mega current usage and the adaptive display based on the amount itself (see above). I'm open to alternative proposals for 0.1 but they need to be more user friendly than what's currently implemented.

I don't remember seeing a game which tries to list point values that differ in many orders of magnitude. If we want to have a single list of all transactions, we need to denote them in the same unit. Another alternative to scientific notation could be to use multiple columns, to make it clear the units are not directly comparable. For example:

Transactions:        (SMH)      (mSMH)     (SMD)
  Sent:                           10
  Received:           2.1       
  Smeshed:            0.2        
  Gas:                                      1000

This is ok if the sum of small units is always less than one big unit, otherwise I think it's a little confusing. Another option could be to use several different lists. For example:

Transaction totals:
  Sent:      <0.01       SMH   (See small transactions)
  Received:    2.1       SMH
  Smeshed:     0.2       SMH

Small transactions:
  Sent:          10      mSMH
  Gas:        <0.01      mSMH (See gas details)

Gas details:
  Total:       1000      SMD

The main point is that we never have to add numbers in different units.

Regarding unit names: I'm not opposed to opening it up to the community, but we have to be careful that we don't end up with Coiny McCoinface... Maybe use testnet coins for voting tokens?

[lrettig]

If we want to have a single list of all transactions, we need to denote them in the same unit. Another alternative to scientific notation could be to use multiple columns

I think we'd need to fall back to the base unit (i.e., SMH) in this case. Every BTC/ETH wallet I've ever used does this, I'm sure it's fine :)

we have to be careful that we don't end up with Coiny McCoinface

The blockchain equivalent would be Shasper McShardface ;)

[avive]

Let's summarize feedback and a plan of action into 1 mini spec:

1. In total we only need 2 units - base accounting unit and the main cryptocurrency name and symbol. The equiv. of Bitcoin/Satoshis and Eth/weis
2. We keep Smesh as main cryptocurrency name and SMH as the symbol / ticker name.
3. We need a name which is not too similar sounding to Smesh and replace it with Smidge. I'm going to talk with Shahar about leading this process together with the community.
4. We need to find a better way to display amounts based on the comments above. Below is a proposal for that.

Regarding other ideas:

1. We def do not want to use scientific notation. Scientific notation is for scientists not ordinary users.
2. We need a solution to display amounts in a small space in most places in clients - and can't show more than one formatting.

Amounts String Formatting Rules

1. When amount smaller than 0.0001 Smesh, display in base unit names using giga, mili, mega, etc... e..g 350 giga-smidge.
2. When amount is equal or larger than 0.0001 Smesh, display in Smesh units. rounded to up to 4 decimal digits. e.g 3.0244 Smesh.
3. When amount is larger than 1,000 smesh, display mega, giga, etc... e.g. 1.0025 mega-Smesh.
4. Hover on an amount in GUI wallets should display the full amount in the accounting unit, e.g. 21,421,412,412 Smidge.

@tal-m @lrettig @noamnelke

[lrettig]

Agree except:

When amount smaller than 1 Smesh, display in base unit names using giga, mili, mega, etc... e..g 350 giga-weaver.

I think 0.1 Smesh is easier on the eyes than, e.g., 1000000 "weaver". We should be comfortable displaying fractions down to 0.001.

[SS-WR]

I agree with Lane.

On Tue, 23 Jun 2020 at 11:30 Lane Rettig notifications@github.com wrote:

Agree except:

When amount smaller than 1 Smesh, display in base unit names using giga, mili, mega, etc... e..g 350 giga-weaver.

I think 0.1 Smesh is easier on the eyes than, e.g., 1000000 "weaver". We should be comfortable displaying fractions down to 0.001.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/spacemeshos/smapp/issues/393#issuecomment-647993881, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOUCDH4Q3OKSWRTNTRU5FX3RYBR3FANCNFSM4KZFNG2Q .

[avive]

I will clarify what I mean - good feedback. When the amount is smaller than 0.0001 smesh then display in base account unit. I think that 0.0001 smesh is 100 mega-smidge.

[avive]

Formatting Rules Examples

Amount (Smidge)	Display
1	1 Smidge
99,999,999	99 mega-Smidge
100,000,000	0.0001 Smesh
1,000,000,000,000	1 Smesh
1,002,500,000,000	1.0025 Smesh
1,000,000,000,000,000,000	1 mega-Smesh

[avive]

Implementation note: use Smidge as the base unit name, until we have a new base unit name decision.

[avive]

Here's a summary of issue and proposed solutions

Unit and Symbol Names

Issue 1: SMH/SMD Smesh/Smidge names are confusing as they are very similar. Action: These were only designed as unit names for 0.1. SS needs to recommend unit names + symbols for 0.2 which are more distinct and the team needs to decide - maybe by vote? Owner: Shahar. Solution: replace with 2 distinct names that don’t sound and with very different symbol names.

Displaying Amounts

Issue 2: Smapp needs to display both very large and very small amounts in constrained space (our core smapp design is mostly fixed size panels and this can’t change for 0.2). For example, a transaction fee or an amount may be a very small number of smidges but the reward is very large amount of smidges.

The current solution: dynamically format an amount based on units which make sense and format amounts to a fixed point fraction so they fit in limited space. E.g. 573.266 SMH. The problem with this is that the user needs to deal with 2 units - Smidge and SMH and that small Smidge amounts are rounded off in a fixed point fraction display string.

Here’s the current formatting algo: https://github.com/spacemeshos/smapp/blob/9c0fc94b7a0786ace55b2499c329abe859a8bf66/app/infra/utils.ts#L27

Issue 3: Smapp needs to display balances and amounts that are large without loss of accuracy. For example, say your balance is 10^12 + 1 Smidge. To display it properly in SMH units the string without rounding to a small number of decimal digits needs to be 1.000000000001 - this will necessitate making the font size in the wallet balance very small - likely 7 or less to fit “1.0000000000001 SMH”.

Current solution: same formatting rules as 2 above.

I don’t have a good solution for this. Electrum for example uses mBTC units by default (1/1000 btc) and doesn’t round-off fractions but its display allows for displaying large decimal fractions.

I’ll be glad to hear about better alt solutions to this issue.

Amounts Input

Issue 4: Smaap needs to enable users to enter both very small and very large smidge amounts. E.g. 1 Smidge for gas and 1SMH for a transfer.

Current solution: all inputs are in smidge units (but there’s a summary view with amount formatted using the best unit using the formatting algo described above).

Current solution makes it hard to send large amounts.

Solution: Have a units drop-down next to every unit input text box which defaults to SMH and accepts fractions as well as integral. Allow user to switch to Smidge units in the drop down. Maybe default gas price to Smidge in the drop-down. This should be implemented for 0.2 in Smapp. See #681

[avive]

Here's one idea to solve issue #3 described above: when an amount looses precision due to fixed decimal fraction display e.g. 1.000 for a 1.0000000001 balance then display a red (i) icon next to the amount. Hover over it will display the full amount in a tool-tip. So 1.000000001 is displayed as 1.000 (i) SMH.

[lrettig]

I don't have an opinion at the moment on Displaying Amounts. Regarding Unit and Symbol Names, as much as I like the names Smesh and Smidge, it's caused a lot of confusion already and we're still only in the testnet phase. As I've been saying for almost a year, we need names that sound very different, with abbreviations that are also very different. In retrospect, "SMH" and "SMD" also weren't great choices.

[avive]

@SS-WR - hopefully coin name picking for 0.2 will leave less people unhappy about them than what was done for 0.1. If we are to change names then the time is now - for your consideration.

[avive]

@tal-m @lrettig @IlyaVi - I'd like to get feedback on the proposed changes for the other issues besides issue 1 before we move this to development for 0.2. For example, the tooltip idea to display small fractions to solve issue 3.

[SS-WR]

Latest community suggestions to replace Smidge:

1. Lilbit
2. Neddy
3. Mish
4. Spacebit
5. Planck
6. Smoshi
7. Skosh
8. Mesh
9. Meh
10. Smit
11. Smol
12. Smix

[lrettig]

I like the tradition (in Bitcoin, Ethereum, and a few other projects) of naming units after brilliant pioneers of their fields, e.g., cryptography or distributed systems. E.g., satoshi, wei (Wei Dai), szabo (Nick Szabo), finney (Hal Finney), etc.

[SS-WR]

agree... great and worthy tradition.

On Thu, Jan 28, 2021 at 2:27 AM Lane Rettig notifications@github.com wrote:

I like the tradition (in Bitcoin, Ethereum, and a few other projects) of naming units after brilliant pioneers of their fields, e.g., cryptography or distributed systems. E.g., satoshi, wei (Wei Dai), szabo (Nick Szabo), finney (Hal Finney), etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spacemeshos/smapp/issues/393#issuecomment-768668856, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOUCDHZ2U5UKTQX7V3PD2ELS4CVQZANCNFSM4KZFNG2Q .

[lrettig]

let's call it a "swartz" in honor of Aaron Swartz. it still fits the "s" theme but it's different enough that it won't be confusing.

[tal-m]

I actually like the name "smidge" a lot more than I like "smesh"... What if we leave smidge alone and instead rename "smesh" to something else? (Something based on "Stelo" could be nice --- it's a former attempt at a world currency by Esperantists, and means "star" which works well with our "space" theme...)

[lrettig]

I like "smidge" too. Okay then, my vote is "smidge" and "swartz" :)

[brusherru]

If I understood right, this issue is outdated since we have already done with https://github.com/spacemeshos/smapp/issues/738. If not, please reopen it ;)