feat: improve repo size labels and explanation

ipfs / ipfs-webui

A frontend for an IPFS Kubo and IPFS Desktop

https://webui.ipfs.io

MIT License

1.55k stars 486 forks source link

feat: improve repo size labels and explanation #1248

Open lidel opened 5 years ago

lidel commented 5 years ago

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?

ericronne commented 5 years ago

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. Artboard Copy 3

B - `A` plus a hover-triggered explainer panel

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

C - `A` plus a click-triggered panel

Similar to above Artboard Copy 2

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 commented 5 years ago

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 commented 5 years ago

I wonder if simply removing all would help.

B

Artboard Copy

C

Artboard Copy 2

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

lidel commented 4 years ago

Yup, dropping all is better :+1: I also would go with C, just for clarity's sake: B introduces problem of having 2019-10-15--01-20-40 and 2019-10-15--01-20-59 pretty close to each other.