ipfs-webui
ipfs-webui copied to clipboard
feat: improve repo size labels and explanation
cc https://github.com/ipfs-shipyard/ipfs-webui/issues/1042, https://github.com/ipfs-shipyard/ipfs-webui/issues/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 https://github.com/ipfs-shipyard/cohosting/issues/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?
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 …
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?
I wonder if simply removing all would help.
B

C

C feels more user friendly to me, but creates slightly more visual noise.
Yup, dropping all is better :+1: I also would go with C, just for clarity's sake:
B introduces problem of having
and
pretty close to each other.
Do we have a panel design? If not, I’ll handle...
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
I dont think this is a bug. It maybe confusing and need some UI adjust but behavior is correct.
I personally like the B approach but would prefer a pattern of tooltip over numbers for more information.
@juliaxbow what do you think?
We will move forward with the C approach previously discussed:



