feat: improve repo size labels and explanation

[lidel]

cc #1042, #629

MFS can store files in "lazy" fashion, which means root is added to MFS, but children are fetched lazily, on first use.

Example

English wikipedia mirror is ~650 GB. Lazy pointer to it can be added to MFS instantly via:

$ ipfs files cp /ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco /en.wikipedia-on-ipfs.org

Problem

This feature of MFS creates a problem in WebUI, it looks like "Files" take more space than "entire repo":

This will become a problem when we start taking advantage of this lazy mode in website cohosting (discussed in ipfs-shipyard/cohosting#6)

Solution?

We need to change the labels, make them more informative.
Below is a quick mock that illustrates what additional information needs to be conveyed.
The problem is that it does not look good, and we need to clean this up somehow.

Thoughts?

[ericronne]

A few ideas which hopefully reflect the state of affairs accurately …

A - Modify two labels

Change the third and fourth labels to "all blocks" and "local repo" respectively, to help explain why the "files" number might be larger.

B - A plus a hover-triggered explainer panel

Add a feature which offers the user text explaining more about the numbers

C - A plus a click-triggered panel

Similar to above

If B or C seem worthwhile and tests well (test? yes let's!), i'll design the full panel. If none fit the bill, we can try something else …

[lidel]

I'd go with B or C: we really need an explainer for these values.
We already have a lot of whitespace on the top of Files screen, so B may save space, but I have no strong feelings here.

@ericronne small clarification: value behind blocks is "the number of blocks" (I have over 600 000 of blocks in my repo). The all blocks label suggests value represents total size used by blocks, but that value is already under local repo. Perhaps we should rename "pins" and "blocks" to something like # of blocks and # of pins to make it clear its not size, but a number of items?

[ericronne]

I wonder if simply removing all would help.

B

C

C feels more user friendly to me, but creates slightly more visual noise.

[lidel]

Yup, dropping all is better 👍 I also would go with C, just for clarity's sake:
B introduces problem of having and pretty close to each other.

[ericronne]

Do we have a panel design? If not, I’ll handle...

[lidel]

Not sure: we have a similar expandable thingy (▶) on Settings screen:

when clicked it expands inline:

We probably should have consistent design in both places (keep/update both), or change > to something else

[hsn10]

I dont think this is a bug. It maybe confusing and need some UI adjust but behavior is correct.

[SgtPooki]

I personally like the B approach but would prefer a pattern of tooltip over numbers for more information.

@juliaxbow what do you think?

[SgtPooki]

We will move forward with the C approach previously discussed:

[lidel]

Mind this issue was created in 2019 and these designs no longer reflect current UI or the way ecosystem and use cases evolved.

For reference, my understanding of the current state (2024-11-14) is:

Files

"Files" represents CumulativeSize from ipfs files stat /[path/in/mfs] (total size of DAG in MFS, does not include any additional blocks and low level pins that are not in MFS, and does not care if data is local or remote)

All Blocks

"All Blocks" is the "everything in local repo" (represents RepoSize from ipfs stats repo)

Honestly, it is not that bad.
We've eliminated "technical noise" like low level pin and block counts, and focused on size of the data.

Most users will not see first number being bigger than the second one, unless they manually imported a big DAG from IPFS, and did not preload it yet.

Perhaps the fix is simpler than one discussed in 2019? We could add a note at the end of "Files" explanation, that it is ok if this number is higher than the second one, and leave it as is.

See proposed fix in #2295

👉 In the future, we could detect if we are in a directory that is not fully local, we could split the first item into "Local Files" and "Remote Files" sizes, but that requires either hacking with block get --offline checks, or optimizing ipfs files stat / --with-local in Kubo.

But for now, I would not over-complicate this UI, and do #2295 instead.