Exact values

[chris-y]

📋 Description

On the Lemmy badge (and I assume others), the value displayed is rounded up to the nearest 1.1k over 1000. Is it possible to display the exact values up to a higher figure?

[M4rtineski]

Lemmy is a small platform and we find exact numbers rather valuable because of hard it is to get them.

[PyvesB]

Hello 👋🏻

The code that governs how numbers get rendered lives here:

shields/services/text-formatters.js

Line 89 in 05f0d86

function metric(n) {

• we could change it. However this would also impact many of our other service badges.
• we could make a special case for Lemmy. This would set a precedent, which could risk increasing code complexity and reducing the consistency of our badges in the long run.

One argument for changing it for all badges is that numbers with unit abbreviations such as k, G, M, etc. are arguably harder to read than their digit-only counterparts. 1.1k technically has the same number of characters as 1187, so we could change the algorithm slightly to not display any abbreviations up to 9999, and leave the behaviour unchanged for all higher numbers.

Would be keen on hearing what other maintainers think.

[chris48s]

So there are probably a few badges where we show a number of things exactly rather than using metric(), but I'd say those are a result of oversight/inconsistency than design. If we can pick out counter-examples where we always show an exact number, we should fix them to use metric.

I think there's a few things to take into account if we are looking at changing metric() aside from number of characters. In fact, I'd never really thought about number of characters as a consideration myself:

• Readability: I'm not sure I have a totally clear view on whether it is easier to parse 1.1k or 1,144 at a glance. I do think 1,144 is preferable to 1144 though. Either way, I'd say readability is the main thing to optimise for here. I'd be really interested if there is any research on this topic as I don't know the answer but I'd be happy to make a decision one way or the other based on evidence.
• One of the main reasons for rounding is that the kind of stats we're reporting (number of stats/download/users/whatever) are indicative rather than authoritative. Do you make a different decision knowing that a package has "1,144" stars rather than "about ~1,100" or knowing that it had "1,144" downloads in the last month rather than "about ~1,100". Probably not.
• This is probably the weakest consideration, but we tend to cache metric badges like this for longer. Rounding is also useful in that context as it smooths over the fact that in some cases the data may be a bit stale anyway.

There's a couple of things I think we shouldn't do:

1. Make a special case for Lemmy. - there's nothing particularly special about this service or stat. We should treat it the same as everything else.
2. Make this configurable via a param. We should make a good decision and apply it consistently.

[PyvesB]

I do think 1,144 is preferable to 1144 though.

I think we need to be careful about introducing separators for large numbers, the above feels like a British/American-centric view of things. People from many other countries will probably wonder whether you meant one point a hundred and forty four, or a thousand one hundred and forty four. I'm personally unable to parse 1,144 for sure without context. 😄

If we really wanted to introduce separators for large numbers from a readability perspective, we should probably use spaces, which is what the International Bureau of Weights and Measure recommends, and which tends to cause less confusion between different cultures.

[chris48s]

This is a really good point. If we go that route, spaces for sure 👍